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

[ik]

On 10/2/06, Daniël Mantione <daniel.mantione at freepascal.org> wrote:
>
>
> Op Mon, 2 Oct 2006, schreef ik:
>
> > > > 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]);
> > ?
>
> It is fnc(a,[b,c,d,d,e,f,g,h,i,j]).
>
> But let's separate the syntactic issue from the functionality:

Well, I think that this is also a functional thing.

>
> * Syntactically, both methods can be safe.
> * Syntactically, the FPC/Delphi one is more powerfull.

Well take a look at the way Java implement it:

.... function varrags(String ... a)
{
   for (int i = 0; i<= a.length; i++)
   {
      a[i] ...
   }
}

varags(a,b,c,d,e,f,g);

The thing I wish that you'll see is that here it's pure array like in
Pascal, but the array is part of the content of the function and not
part of the parameter usage ... (I can btw also use different types,
so we solve the problem of unsafe types).

BTW in perl every group of scalars are actually an array... there is
no difference .

> * Functionally, the C method is not safe, while the FPC/Delphi one is.
> * Functionally, the FPC/Delphi method has more runtime overhead than the
>   C one.
>
> > The [] is the same as "InitbyObject". It's informative, but not really needed.
>
> The [] is the mechanism that allows you to pass multiple arrays.

I don't understand what you mean :(

>
> > > > 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 ...
> >
> > ?
>
> Huh, I don't understand this?

If I will not add any parameter, I could check inside the function if
the parameter is initilized rather then checking for length, so []
will be for 0 items while, no "[]" will be no parameters at all.

>
> > >
> > > > 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 ...
>
> Well, if it were to the Free Pascal developers, there would be no default
> values at all :) We heavily grumbled when we had to implement it to be
> Delphi compatible.

But we can see how good and helpful it is and can accept it :)

>
> > 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.
>
> I don't understand this either.

With an integer parameter, you can place "0" for example as default
parameter, so with open array, you could also place default paramters,
when #0 was just an example for that.

>
> > > > 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".
>
> On the contrary. I think we can consider constant arrays native? Then
> there is nothing about bad about reusing the principle. IMHO. Feel free to
> differ, but I consider the [] solution much more elegant than the C
> varargs.

Yes and no, it is more elegant, but with few prices ...

>
>
> > > > 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 ... :(
>
> Let me show you a very elegant use of the FPC language. We'll be
> implementing a printf style thing, but nicer:
>
> type   help_type=type string;
>
> operator :=(s:string):help_type;
>
> begin
>   result:=help_type(s);
> end;
>
> operator :=(s:longint):help_type;
>
> begin
>   val(s,result);
> end;
>
> procedure printf_improved(const s:string;args:array of help_type);
>
> {This will format a string like 'We have $1 apples and $2 pears' and
>  print it.}
>
> begin
>   {...}
> end;
>
> function localized_strings(var format,colour,thing:string);
>
> begin
>   if language=english then
>     begin
>       format:='A $1 $2';
>       colour:='red';
>       thing:='wine';
>     end;
>   if language=italiano then
>     begin
>       format:='Un $2 $1';  {In Italian the subject comes first.}
>       colour:='vino';
>       thing:='rosso';
>     end;
> end;
>
> var format,colour,thing:string;
>
> begin
>   printf_improved('We have $1 apples and $2 pears',[1,5]);
>   printf_improved('The value of variable b is',[b]);
>   localized_strings(format,colour,thing);
>   printf_improved(format,[colour,thing]);
> end.
>
>
> Now this example has many advantages over the C printf:
> * It is type safe.
> * It doesn't pull in unnecessary code into the executable, for example
>   the boolean print code does not appear into the exe if we do not need
>   it.
> * The parameters can swap positions, so it is much more powerfull for
>   translations.
>
> Can you do this with C? I fear not. Show it to a C programmer and he'll be
> convinced Pascal has some amazingly powerfull features.
>
> > > > 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! ;))
>
> Actually I agree with you here.

Finally :) What does it take to make it non object oriented thingy,
that is, it can be used on $MODE FPC ?

>
> > 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 .
>
> Huh?!! Again I am lost.

I'd seen hacks to find what is the parameter type (in delphi), by
getting the memory address of that paramter, and the position inside a
range of memory that the parameter located at, reprisent the type of
that parameter.

>
> > 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)
>
> I don't think there is an alternative here. If you would pass an array of
> pointers, you would get into trouble when passing integers. (Pascal
> is type safe.) Record variants are the only sensible solution.

I do not like variants. They are very memory weasting type, and most
of the time operator overloading might make a better job.

>
> > > 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.
>
> This is exactly what we thought when coding this.
>
> > > 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 :( )
>
> Sure! Just accept that sometimes things will work differently than in C,
> Pascal is not C, even if it is at least as powerfull.

But sometimes you can take things and make them better.
I coded a lot in perl and recently I started coding in ruby, and I
have expirence with a lot of other script based languages (like Java,
nasl and more). Every time someone try to make a more "perfect"
language, the solution looks more like a Pascal solution (even by
syntax), rather then C and C++ like solution ...

In my language there is a saying of "the show makers always walk
barefoot naked", why don't we make this a false sentence for Pascal ?

>
> Daniël
>

Ido