[fpc-devel] va(r)_arg vs open array

[Marco van de Voort]

> On 10/3/06, Marco van de Voort <marcov at stack.nl> wrote:
> > >
> > > I agree here, but as I said (I hope), you need some sort of compiler
> > > directive to enable such thing. By default it should accept only []. I
> > > agree with that. And as I said before, this is a petty thing only.
> >
> > Not every changement is a improvement. There is not merit in supporting
> > more ambiguous syntax here. Retrain the few C bigots that keep whining
> > about it.
> 
> Ambiguous syntax ?! how parameters placed like in normal syntax, can
> be ambiguous ?

{$mode objfpc}
procedure bla;
begin
  writeln('bla');
end;
procedure bla(v:array of const);
begin
  writeln('bla[]');
end;

begin
 bla;
 bla([]);
end.

> > > BTW STL as far as I know (I don't know a lot of things regarding STL) try
> > > (and maybe did) solve this problems.
> >
> > STL is afaik very tied to a static (or dynamic with GC at a severe
> > performance penalty) object model. From what I've seen from it the concepts
> > don't work for FPC/Delphi objects.
> 
> "Fish for an hungry person and he will eat for a day, teach a person
> to fish, and he could eat every day"

Ah, silly sayings time!

"Give fish to a veganist and you will have wasted a few minutes. Teach him
to fish, and you will have wasted days".
 
> Why do you need literal translation of things ?

Because I actually did think about these things. I ported Decal, and saw to
what lengths you have to go to keep the STL principles running under Object
Pascal

And that's becasue a static objectmodel (or something that can emulate it
like dynamic model that is autmatically memory managed) is pretty much a
requirement for the STL as it is. (Decal emulated it with interfaces that
are refcounted to workaround this. The performance is worse than something
like Java or .NET)

> Why not make them fit
> to the Pascal way, but learn from the good thing they have ?

Hollow phrase. If you think I didn't get some lesson from the STL, why don't
you simply say what I didn't get?

It is all so vague? We should learn from this, and the greatness of that,
but all you've shown so far is one pretty ugly shorthand([]), and the extension
of array of const to fpc mode. (which I do not object if possible)

> > case, in the next step after the initial discussion, if you still persist)
> 
> Well
> A. I find that the use of [] makes a lot of people to make mistakes
> because the concept is alian to them, and for some strange reason not
> using it, make them use the feature better.

If people don't want to learn a language, they will just fall into the next
trap. And teaching a systematic, orthogonal language is much easier.
 
(snip lots of arguments which are all just trying to make a case for "do
like C", IMHO without any merit. 

In the 5 years array of const support, I _never_ saw such a problem
mentioned, or any problem or misconception about it that wasn't solved by
providing the link to the manual part that describes it.

I don't see the need for any syntax changes and extra directives.

Hmm, on second thought, a few pooints  I do want to respond to though,

> 3. Compatibility with other languages. It will make easier porting
> from one language to another, including translating things with less
> possible bug due to syntax.

The compability is _so_ superficial that it only will confuse people more.
It is different and that isn't solved by trying to make the most superficial
syntax. 

E.g. C I can do all kinds of dirty tricks, like pass a pointer to where the
runtime expects a long, and it will print the address. With Array of Const
that generally won't work.

> 4. Focusing on the task, rather then on the syntax symbols.

>  When you are working fast to solve bugs under a lot of pressure, you find
> yourself try to fix opening and closing of [], and you find yourself place
> new parameters outside them, just because of speed, the fact that you are
> tied etc...

Having them look in the manual for the directive won't solve this either.
And the bugs introduced by this careless switching off can be way harder to
trace. See above example.

> 5. Understanding that compiler magic, sometimes needed also
> for non compiler creation. the TParameters that is used under Writeln,
> should not be a compiler magic imho.

TParameters?
 
> Pros for using array of const in FPC mode:
> A. instead of using overload of any possible type for specific array
> of integer, array of string etc... You could add in a non object
> oriented mode a list of multiple types in one parameter.
> B. The ability to write lower level applications with tools that
> exists only in higher level.
> C. Easier software design, that will require less hacking to solve
> problems of multiple parameter list.
> 
> Cons:
> A. Not compatible with Wirth Pascal.
> B. Making additional overwork for the FPC team.
> C. Make Pascal developer write less overloaded functions.
> D. Make it closer to Java/C syntax.
> E. Divide the FPC developers/users to groups of Pro and Cons.

Pros:
A. A solid, safe, unambiguous and logical language feature

Cons:
A. None.
B. It is not standard Pascal, but hey, neither is probably 90% of FPCs
other language features.

Perceived Cons:
A. It is not 1:1 mappable to C. Or Java. The fact that these don't map 1:1
to eachother doesn't matter.
B. Another 50% of FPC features is not mappable to C. Maybe we should get rid
of sets too.

> > More than any language afaik. I saw numbers once like 70% of paid
> > programmers are said to work in VB/.NET, though maybe eroded a bit lately by
> > moving to C#.
> 
> And still I do not find anything good that VB have to offer us ...

(advocate of the devil mode on)
But maybe they will port code too, and fall into loops. Maybe we can better
cater to them, since they are the larger group.

I don't see much use in adding more C constructs too. Half of the ones we
have are only for C interfacing, or interfacing to C api's (e.g. array of
const varargs style). Not for being 1:1 mappable to C.

> It's a language that should have never evolved.. it's a freak of the
> programming language nature... Every Hugh task at the end pointed to C
> or C++ solution when you just call a library at the end.

I don't am that fond about C and C++ either. IMHO C++ never had a chance
because of backwards compability to C (and even Java and C# suffer from
this). And half of C's designs is just a result of the original implementors
designing the language to avoid as much state in the compiler as possible
(external preprocessor to define a constant!??!), so they could compile
large kernels (think 20 kwords) with the limited memory they had on the
PDP-7.
 
> C# is Java by Microsoft. Pure and Simple... I still do not see what
> good it gives either, alto 

> If we have Microsoft on our side, FPC had a
> lot more developers and users .

I don't buy that. The bulk of the developers will go with Microsoft, and
Microsoft only. They select Microsoft, they don't select .NET.

Delphi.NET has less users than Delphi had. Why? Borland can't keep up with
MS, and users don't want to be a minority (for components, access to new OS
api's etc) a second time, and move directly to the MS prefered solution.

The only way to deal with Microsoft in the commercial world is to entirely
avoid it, or to entirely embrace it. And with embrace I don't mean to port
to .NET, but to change to MICROSOFTS .NET toolchain, and Microsofts toolchain
alone (forget about stopgaps as Mono, Delphi.NET etc).

I learned that the hard way, using Borland C++. 99% of the components,
source etc had to be ported, begged for special versions with the vendor etc
etc, just to work with BCB, since it was all designed for MSVC++ and MSVC++
only, despite being "portable" C++. It will be the same with .NET in
practice, despite what a few dreamers think. Simply because the people that
go for .NET are all of the kind that want to be closer to Microsoft, not
more apart from it.

Delphi was one of the few exceptions for a while on win32. Commercial in
competition with MS, it could keep double digit market share for a while as
only one, but either Borland neglected a bit too much, or Microsoft became
to strong. It doesn't matter (but I think it was a combination of both) ,and
it is pretty much over, except for those that either stik to MS, or don't
buy the .NET saga.

Seeing that MS didn't even manage convert 0.1% of windows to .NET makes the
"in n years, everything will be .NET" somewhat unrealistic IMHO :-)

Oh, and nobody, really NOBODY that ever proposed a feature to FPC managed to
avoid  "and I think this will get FPC a lot of extra users"
standard line. IOW, EVERYBODY dangled that sausage in front of us. 

And that includes me, both before and even after I became core. And the
others made me see the trouble of some of my proposals.

And keep in mind, while I wrote the .NET faq, and I also wrote the faq about
extensions. But I showed them to the other developers before it went live,
and they pretty much all agreed.

(actually the sentence that starts with "if sb does the bulk of the work" is
one of the compromises out of those discussions. But I agreed with that
modification too)

> > But probably there will be a reason. Some form of disambiguation that this
> > comma provides.
> 
> VB love parameters, even if you could have simply solve it by using
> OOP approach, or using records... That's the only reason.

See Michael's mail.

> > > varargs allow me to add unknown amount of parameters without
> > > overloading a function with 500 calling to answer all the 500
> > > parameters i might need.
> >
> > You don't know if there are any parameters.
> 
> Sure you can... va_start return to you how many parameters exists on a
> va_list ...

No it doesn't. va_start says how many parametes are in the argument string.
If you pass less parameters, it will horribly crash.

> > > It's not a bad situation to have 500 functions with all the possible
> > > parameters I might need ?
> >
> > I think I'll print that sentence out, frame it, and hang it on the wall :-)
> 
> Cool, send me a picture :D

Maybe it is something for the anti-patterns club :-)

> Now I had one function that fills few texts (depends on the parameter
> situation) and return the string that was filled with %s %d  etc
> formats. Now one field can be used more then once. And almost every
> line have at least one format string. So you need to pass the format
> function a lot of parameters, in order to complete the form.

(snip)
And when you insert, you have to count carefully in both the calling
function and the result function.

A sane way would be to make a list of data that uses name,value pairs to
substitute each name with its corresponding value.

And you can then pass this happily around, append parts, and you decoupled
the horrible order dependancy that is not necessary, and created
maintainable code.
 
> > The latter one is doubtfull indeed, but very old, and I'm not happy with
> > them, except maybe the ++/-- variants. These I use sometimes though, since
> > it avoids translation errors when C code uses the ++/-- in a loop without
> > rearranging and retesting them.
> 
> I don't use ++ -- unless that's the writing convention on the language
> I use. In pascal I use inc and dec ... I find ++ and -- really
> annoying thing, due to the --i i-- thing, that I always do not
> remember what first implement and then return value and what is first
> return a value and then implement...

(I just wanted to be fair, and not slam that functionality while I actually
used it with FPC, though a handful times in 10 years)
 
> I also do not like GoTo and we still have it on FPC, also there is a
> switch to turn it on/off (like what I think should be for my offer).

Ah, but we already had goto, and then made the switch. You propose to ADD a
goto.

> > The FPC macro support is not C compatible, and just like operator
> > overloading makes something possible, that can't be done otherwise.
> 
> I still did not find a real use for macros in FPC, but you are more
> then welcome to open my eyes .

The main place it is used for is for calling convention modifiers. A use
that is also pretty common in C libraries.

(from my mind)

{$ifdef win32}
{$define mycalling=stdcall}
{$else}
{$define mycalling=cdecl}
{$endif}

procedure xx; mycalling; external 'libraryname' name 'externalname';

> > This is not the case here, since there is array of const.
> 
> But only for specific modes that require you object oriented support.

I've already said I'm not against that. But maybe that will be difficult,
and causes the loss of the smaller footprint that the non Object Pascal
modes have.

> I never develop things to "show people" .. I develop things to make
> them work. And this one will make my and even your work much easier in
> few ways...

Not mine. As I said, I never encountered any wish about this before. In say
the 7 years of object pascal functionality.

There have been some issues with array of const in the past, but they were
all about C interop (being able to call C varargs). Not C source level
compability.

> > > But people can build houses from rocks, so they think that only rocks
> > > can create houses.
> >
> > Yeah, but rocks can't, which was the point.
> 
> Rock can't build a house or rocks can not be a house ?

Rocks can't build a house.

> > No you don't. You take what is the best for the house, and demonstrate that.
> > And that is array of const.
> 
> Please work with "regular" people. You first need to speak their
> language (in this case build a house from rocks), before you can try
> to communicate with them.

I work with regular people. I have been doing FPC support for quite some
time, answering messages, closing bugreports etc etc. And therefore I know
first hand that any new syntax causes a certain amount of problems (rise in
support pertaining to that issue). Specially if you have multiple variants
and nuances of the feature. 

That is not always unavoidable (e.g. we do support array of const
cdecl/varargs), but it must be really worth it (e.g. being able to complete
the interface to compiled C functions, varargs was the last major thing we
couldn't do), and not superficial typing.

Keep in mind that you only see people having some initial problem with FPC,
and then they move on, and come into the FPC support channels. (forum,
maillists, personal mail, bug tracker), and contact us directly.

> > > But this support only exists for object oriented usage in the mode of
> > > Delphi and OBJFPC, I find it helpful to have it also in FPC mode !
> >
> > I don't care about that.
> 
> I do ! so why not help me to make my life easier when I'm using FPC ?

I meant "I'm not against that". Though I maybe see practical problems. But I
maybe there is an obvious workaround for that. I'll leave that to the
compiler devels.

> > Generics are in place. They are also potentially confusing etc etc, but at
> > least they make stuff possible that isn't possible otherwise, which is worth
> > the shot. It is not just about typing and catering to the C crowd.
> 
> Many things that C++ developers showed me that templates (generics)
> makes their life easier, I showed them how I don't need it in Pascal,
> and still have the result... you sometimes need to see that there is
> no spoon and it is your mind that is spinning  ;)

Show me a generic typesafe container. Fully typesafe. Even Decal doesn't.

> > Define more flexible. I don't care about the modes if it is possible. (some
> > parts of tvarrec might be objpas specific)
> 
> It is not possible. If it was possible, it would have worked on all
> "native" modes (except TP).

FPC is not fully static. Things we kept strictly separate in 1.0 might be
more lax in 2.0. So while there is a fair chance that it indeed is not
possible, it is not 100% certainly so. E.g. in 1.0 times we cared way more
about the size of a minimal problem using the default RTL than nowadays.
 
> That's why it feels more like a hack imho ...

No. I was there. The decision to keep them apart were IIRC twofold:
- avoid identifier space polution by the new delphi units which might be a
problem for TP code. (so identifiers added in the Delphi system could cause
trouble for existing TP programs that already defined that identifier)
- footprint.

> > > You are more then welcome to help me doing so :) You can start by
> > > creating exception handler for a kernel, so I could enter OBJFPC ...
> > > (My "OS" try to be pure 64 bit)
> >
> > I'm perfectly happy with my current selection of OSes.
> 
> But I'm not for few reasons:
> 1. No Pascal OS .

Use classic Mac OS versions (:-))

> 2. I need to choose between *nix or between radmond (that getting
> closer and closer to *nix), and they are both not what I'm looking for
> (Mac tiger is a *nix).

OS X is a mach kernel (even though it has a very vast Unix userland). So is
Windows NT (at least the original design), BeOS, Minix (direct precursor to
Linux in some ways).

You could say the unix part of OS X is a module.

> 3. Almost all existed OS are some type of monolithic kernel... So I
> can't just change the way that the kernel handle memory, or how it
> will support file system. I can only make it additional modules that
> in the best case, will override existed way.

See Mach OS.

> 4. Too much patching (of features) make your OS act bad.

Not just OSes. Also languages :)

> 5.  It's hard to make an OS that will be suited for 100% of your
> needs, you need to compromise ...

I agree. More generally for all software. However OSes is particularly hard
due to the driver problem. All minor OSes (and even some major) are
struggling to get enough hardware support.

The first question I ask a new OS developer is that.

> 6. I always see room to improve things to make them better, and then
> some Marco comes and tells me that he is more happy with the existing
> features and fight me :P

That's because Marco sees, and has seen some of the problems that not
carefully crafted extensions can cause. Specially extensions that are very
emotionally driven. 

It is not that I'm holy or always right. On the contrary; it's because I
also made these mistakes. (and probably even worse ones, and still do once
in a while). Usually the compiler devels (typically Peter/Florian/Jonas)
made me see I made idiotic suggestions.

This process pretty much was the reason for the FAQ entry about compiler
extensions. After its inception, a few people have managed to make a real
point using example implementations and a lot of reviewing, and got them
accepted.