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

[Marco van de Voort]

> On 10/2/06, Marco van de Voort <marcov at stack.nl> wrote:

> > The type of a is secure in the second part, and it is faster. Keep in mind
> > that more elaborate syntax increases the chance of copying/referencecount
> > changing etc etc.
> >
> > E.g. the standard example is printf. There the first type must be a string
> > according to C, and this is (hopefully) enforced.
> 
> 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.

> >
> > Because that forces by reference and dynamic memory allocation. We don't
> > want to become Java either. Again, there are possibilities with sane reasons
> > between C and Java.
> 
> But we can learn from C 

What? The varargs thing is not something to learn, since unsafe and
ambigious (no trailing arguments possible)

> and we can learn from Java.

What? 

> 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.

> > In theory there could. I don't really see thet use, since the procedure can
> > detect that no other params are following
> 
> There is no need for default values for scalars as well, because we
> can add their value inside the function, but still sometimes it can
> help you.

Again falls in the category "typing only". If you add syntax for each and
every shortcut that "could help you sometimes" (translate: save a few
keystrokes), you end up with something even worse than Perl.
 
> > However for that see the FAQ about new features, and specially the part
> > about inventing syntax to save a few keystrokes.

I would like to emphasize this once more. It was written after countless
discussions like this, and with a reason:

http://www.freepascal.org/faq.html#extensionselect

All four points (the three explicitely named, and the requirement that
future extensions should be more than a oneliner idea, but a complete
reviewable proposal for a solution) apply to this discussion. (or in the 4th
case, in the next step after the initial discussion, if you still persist)

> > What's next, people on Windows to implement the whole of VB syntax, because
> > that is the dominant languag there?
> 
> Last time I checked VB is more dominant language then delphi and other
> languages.

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#.

> But the response is not correct.
> For example, I do not like the fact in VB that I must use "," without
> parameter if I "don't' want to use" this parameters.

But probably there will be a reason. Some form of disambiguation that this
comma provides.

> Why is it so important for you that it will not be implemented ? I
> still do not understand your point of view... sorry :(

Well, first, I still don't know what you want, except that you want to get
optionally rid of [] in array of const statements with no leading or
trailing normal parameters to save two characters of typing and because it
is more C like, neither of which is IMHO worth the trouble.

The broader reason is that I'd like to keep a clean language. Extensions
like this are useless ballast. The more extensions you have, the bigger
chance in conflicting (as can be seen very clearly in the string types
automatic conversions in combinations with stuff like overloading, default
params etc)

> > But that is not what varargs is. Varargs just end pretty much any checking
> > of the variant parts. And for interfacing we support somewhat it as cdecled
> 
> 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. 

> > > I think there is a function like this in the FPC core source.
> > > That's makes Pascal useless on such types of needs :( Or as someone
> >
> > No it does not. Don't confuse the subject. It means a C programmer will have
> > to learn a bit of two. I don't think this is a bad situation.
> 
> 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 :-)

If you have such a case, it is a bad architecture of the software. 

> > That is just kidding. Seriously, don't take the whining to seriously. The
> > next thing they want will be macro's etc etc.
> 
> The person who told that is a Pascal developer .. and last time I
> checked we do have macro and even operator overloads. Oh and also the
> implementation of += -= i++ etc... too late :)

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.

The FPC macro support is not C compatible, and just like operator
overloading makes something possible, that can't be done otherwise.

This is not the case here, since there is array of const.

> > If you will grant them every wish, better start using C immediately, since
> > nothing else will satisfy them (and you pay the price in safety and
> > productivity, not them !)
> 
> "If you show the other side that you have problems they win" I never
> agreed with that point of view ..

Then develop your interface without regarding people that just whine because
it isn't C.

> There is a difference between a need for something to make better and
> easier work, between "look ma, I can access the system by spinning all
> over the place".

Well, the latter is varargs. No checking done.

> > You can't teach a rock to dance. C is about as smart as a rock, higher level
> > concepts are totally alien to it.  array of const;cdecl; is limited, unsafe,
> > and a natural fit for C.
> 
> 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.

> If you want to teach people how to create houses
> with other materials, you need to show them first that you can create
> it with rocks, and show them something better after that imho...

No you don't. You take what is the best for the house, and demonstrate that.
And that is array of const.

> > Then give an example. I still haven't heard a real reason (let alone that it
> > is reason enough). We already confirmed that you can be fully equal to C
> > (array of const;cdecl);. What else can we do? Provide C header files that
> > provide va_start macro's?
> 
> 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 also see the need to make it even better, by making it more flexible
> that I can do things depends on my needs, instead of the place i am
> at.

Then write a proposal. 

> > And probably rejected ten times as much proposals that didn't make it. And
> > a lot of the changes involve coming down from the ivory tower.
> 
> You never know what's going on under the sun ... But still they added
> generics, and now there are smarter containers. They fixed a lot of
> bad ways to do things, and Java is more used the Pascal ...

Give us the financing Java has, and we'll show you what you can do in
Pascal:-)

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.

> > True. I never said we don't do extensions. There even is a faq entry about
> > doing extensions, and I'll summarize it here:
> > - must make something possible not doable otherwise, not just be shorthand.
> 
> What is not possible in making open array more flexible and make it
> work in more modes then Delphi and ObjFPC ?

Define more flexible. I don't care about the modes if it is possible. (some
parts of tvarrec might be objpas specific)
 
> > To be honest, I still don't have a clue what you still need over array of
> > const;cdecl. However if I would develop an OS, I'd force array of const
> > semantics on programmers, on all calls except the ones the language wants
> > old-skool, and I'd overload even those with array of const, and find some
> > clever synthesis functions/macro's for them.
> 
> 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.