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

[ik]

On 10/2/06, Marco van de Voort <marcov at stack.nl> wrote:
> > On 10/2/06, Marco van de Voort <marcov at stack.nl> wrote:
> > > > 1. It's not a va_args.
> > >
> > > So? Other language, other syntax. We don't use {} either.
> >
> > Sure you do, {$include file.inc} {$H+} {Comment} We just don't use it
> > as the C syntax wishes ...
>
> I hope it was obvious that I meant blocks.

I meant that we are using things for different usage. We do have blocks, we have
begin end
we have try finally/except end (I have also remarks on those but not
for this discussion).

And for some usages we have [] and () blocks as well.

The thing is we have blocks.

>
> > > > 2. The usage of [].
> > >
> > > Same. Penalty for being safe. It is also required being able to mix non
> > > array of const and normal parameters.
> >
> > What is the difference ? I mean, what is the difference between
> > fnc(a,b,c,d,e,f,g,h,i,j);
> > and
> > fnc(a,[bcdefghij]);
> > ?
>
> 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.

>
> > On both cases I can add 0..n amount of variables ... but ", , , , , ,"
> > without [] imho is more intuitive.
>
> That's because of C mindset, and C mindset alone. What about parameters
> AFTER the varargs that are definite in type?
>
> {$mode delphi}
>
> procedure x(a:integer;b:array of const;c:integer);
>
> begin
>
> end;
>
> var a ,b,c,d,e : Integer;
>
> begin
>   x(a,[b,c,d],e);
> end.
>

I agree here for 100% with the need for [], and I understand the power
it gives, but I still think that we should have a choice here.

> > > > 3. Even empty parameter must have [] instead of not calling it. It's
> > > > like C that must have empty () when calling a function ...
> > >
> > > C has no checking what so ever, we want to do better.
> >
> > Cool, but if you want to do better, then lets get one step further and
> > say that nil value does not need to be "0 amount of values" in the
> > parameter usage itself. Why not just to check
> >
> > if (not openarray = nil) then ...
>
> 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 and we can learn from Java. BTW STL as far as
I know (I don't know a lot of things regarding STL) try (and maybe
did) solve this problems.

>
> > > > 4. I can't add default values to that type of parameter.
> > >
> > > Can you in C?
> >
> > No, but Pascal is better then C imho ... :) and as long as we have
> > "var", "const" or "value" we should have default value (if we wish)
> > imho ...
>
> 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.

>
>
> procedure x(a:array of const);
>
> begin
>   if high(a)>3  then
>     begin
>      param4:=1;
>      param5:=2;
>     end;
> end;
>
> Also note that this works with trailing parameters too (since they don't
> count in high())
>
> > Now even if I do not have any value inside, I want a value to print,
> > lets say #0, why should I start making "if" and checks to see the
> > length of the openarray, when I can just "print" the value for
> > example.
>
> No need to have a default. Just a rule that writeln([]) is equivalent to
> writeln;.
>
> However for that see the FAQ about new features, and specially the part
> about inventing syntax to save a few keystrokes.
>
> > > > 5. Feel like an hack.
> > >
> > > Where do you get that feeling?
> >
> > "OK, so I don't have a way to make a compiler voodoo magic, but I can
> > use an open array to get the closer feeling", but as Daniel say, in
> > order to complete the usage of such thing, I need a synthetic sugar,
> > and that does not implemented... It does not feel native ... it feels
> > like a patch/hack that was added to shout people up when they say "you
> > do not have var args".
>
> No it isn't. It is more. The need is real, but there was no need to keep it
> similar to C's 1970 syntax that was invented to keep the compiler in
> 20kwords.
>
> There are already several differences:
> 1 non array of const parameters can follow the array of const
> 2 typesafety.
> 3 middle road performance wise. (a sacrifice for (2))
>
> > > > 6. Try to explain that to a C developer... it easier to bash your head
> > > > against the wall
> > >
> > > Then don't do it. Let the C runtime solve his interface problem for him, and
> > > only provide (2) calls.
> >
> > Well I'm going soon to raise my presentation in a Linux club (I still
> > have to have an answer from the organisers of two of that Linux
> > clubs), and one of the questions that someone will ask (actually
> > tease) on many unsupported things... now try to face such questions
> > that you can not escape from ... I can't answer such teasing when I
> > think someone is right ... :(
>
> 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. 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. This is a bad
practice, but if you find it important, I will accept the fact that
you need it, alto I will not agree with it.

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

>
> Moreover you probably stepped over the Daniel's mentioning that cdecl'ed array of const is
> varargs like.

I didn't stepped over... I also found that you have directive called
"vararg" that I can place... but that is not the point, and I didn't
had anything to say about it (no pro or con, so I didn't talked about
it).

>
> > > > 7. Require delphi/objfpc modes.
> > >
> > > So? It is higher level functionality.
> >
> > So, if I do not need OOP, I must do an overloading of
> > fnc(a :..) ..
> > fnc (a,b :..) ..
> > fnc (a,b,c : ..) ..
> > fnc (a,b,c,d : ...) ..
>
> 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.

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

>
> > told me "if you don't like this, just use C instead" .
>
> I think it is the other way around. You should say "if you don't like it,
> you should Pascal instead?"
>
> 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 :)

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

>
> > > > 8. Have a record inside that tells you the type of the parameter (that
> > > > is also a pro as much as it con)
> > >
> > > Only on the inside. Your application programmer won't notice this.
> >
> > Back in the Delphi2-3 days (maybe its till exists), there was a hack
> > that if a variable is from a range of 000000..111111 it is an integer,
> > if the range of the memory is 222222..333333 the variable is float, if
> > it's AAAAAA..FFFFFF it's a class etc.. you don't expect any developer
> > to go that law to know such things ... specially, that it is not a
> > constant thing on every OS and arch .
>
> That's why Delphi/FPC learned from the C trap, and used the constants, so
> you won't need these hacks.
>
> > > > 9. I feel like it limiting the type of usage I can do with it because
> > > > it support only "basic" types of parameters (according to the example
> > > > in the documentation:
> > > > http://www.freepascal.org/docs-html/ref/refsu47.html#x113-12000010.3.6).
> > >
> > > You can pass any class, and, after verifying it is a class, further
> > > discriminate using object.classtype and/or is/as operators
> >
> > So how good are we then the C developers, that pointers are like air
> > to them, even on places no other language really needs them (including
> > c++) ?
>
> 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. 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...

>
> > > > There might be probably more reasons why not to use open arrays, but I
> > > > can't think on more at the moment.
> > >
> > > Basically all are "it is not both C and Java". Well, it isn't. It is
> > > FPC/Delphi.
> >
> > Yes, but while most C compilers does not fully support K&R syntax and
> > supports, and uses a lot of hacks and "patches like" ways to do
> > things, we the Pascal developers, are better, smarter (ahmmm most of
> > you ;)), and can solve things in a much different way then the C
> > developers. But still some problems better solved in C then in Pascal
> > (such as the synthetic usage of var_args).
>
> 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 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.

>
> > Java is a way too clean and too resource consuming language to begin
> > with. But Java 1.5 added a lot of things that many Java developers
> > were crying to have for a lot of time...
>
> 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 ...

>
> > People working to add support for generics for FPC alto you do not
> > have a standard for it. FPC added a lot of support that is not added
> > by any other modern Pascal compiler out there.
>
> 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 ?

> - fit in with the scope of the language.

I don't understand why it does not belong to that ... :(

>
> > But here we have something that I know of many people that actually will
> > need it. Even if they don't know it yet, the second it will be out, they
> > will use it, and will not understand why it wasn't implemented before, or
> > how did they manage things before.
>
> 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)

Ido