[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, Dani?l Mantione <daniel.mantione at freepascal.org> wrote:
> > >
> > > Syntactically you cannot. However, the array of const is just as powerfull
> > > (actually more powerfull, since you can pass multiple arrays). We consider
> > > adding a trick to make it syntactically behave like writeln unnecessary.
> >
> > But in vtype I can't know if I got array or not, and I can't know if
> > that's a record. :(
>
> You can't in C either. C varargs everything is "if string and arguments
> match it won't crash".
>
> > > > to make it possible to add such feature to FPC ?
> > >
> > > Show the problem with array if const first :)
> >
> > Lets start from the pity ones to the real problems :)
> >
> > 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 ...

>
> > 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]);
?

On both cases I can add 0..n amount of variables ... but ", , , , , ,"
without [] imho is more intuitive. I don't need to know how the
parameters where implemented inside the function.. I need only to know
how to use the function ...

Think on lets say a function name "Init", it tells me that it
initialize something, it does not tell me how it initialize it... now
if I'll call it "InitbyObject" will tell me that it uses Object to
initialize things.

The [] is the same as "InitbyObject". It's informative, but not really needed.

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

?

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

Lets say I wish to have the following procedure:

Writeln

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.

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

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

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

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
told me "if you don't like this, just use C instead" . And that's not
an answer I like to hear ... (when everything else fails, use
assembly, not C! ;))

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

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

"Maybe we should use object like variable types ?" (don't even bother
to answer, I don't want such a thing)

>
> > 10. I feel that there is not enough documentation about it.
>
> Look for "Essential Pascal".
>
> > 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).

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

>
> Even if you want to make a comparison, make one, and then also list the
> disadvantages of the solution (like the horrible security model of C, or the
> runtime overhead of Java)

I don't want a C or Java like compiler, I want that people from C or
Java will find out that Pascal is able to do things, they can only
dream on, and they will try to take it for themself.

Ours is not only bigger, but also better (on most things, but it's not
perfect :( )

Ido