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

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

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

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

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


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?

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

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

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

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 !)

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

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

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

> 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.
- fit in with the scope of the language.

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