Variable number of parameters

Tue, 11 Mar 1997 23:04:01 +0100 (MET)

Hello, everybody!

According to Frank Heckenbach:
> In news:comp.lang.pascal.borland, there's just a discussion about
> variable number/types of procedure/function parameters going on.

Here are just a few remarks from me to clarify some points; right now I
don't have the time to enter the discussion in comp.lang.pascal.borland.
I'll join you next week (-;unless our news server is down again).

> Not explicitly call itoa(), but (s)he'd have to specify the type by a format 
> specifier ("%d") in the format string. This, of course, provides no means of 
> type checking, and is therefore not suited for Pascal.

I agree; however Borland has had something like this ("Form" procedure) in
Turbo87 3.0 and something similar in Turbo Vision ("FormatStr" procedure),
and you can call C functions like "printf" from GPC using the declaration

    Function Printf ( format: CString; ... ): Integer;

(Yes, with three dots.)

> But this would be a case for default values as in C++. If you could declare
> something like
>  procedure LPP(s:String;segg,off:Word;PPal:PPalettestructure value NIL);
> and call it with wither 3 or 4 parameters (in the former case, the 4th 
> parameter would be implicitly NIL), that would be nice sometimes...

Yes, that would be nice .  But it's work, of course.
Any help welcome!

> I don't think there's anything wrong with it, but Borland will not do it.
> They've dropped TP, face it! So if you want these changes, don't look at
> TP, but perhaps at GNU Pascal.

:-)

> AFAIK, gpc already supports declaring and
> calling a procedure with variable arguments, like C - but only to allow
> calling C functions with varargs. There's not (yet) a way to implement such
> a procedure in Pascal,

Correct.

> but the gpc developers are always looking to enhance
> the language, so if you've got some concrete ideas (or can even help to work
> on the compiler), you're always welcome to join the team.

Correct ** 2.  :-) ;-)

> > Thats not what I where aiming at. You could make the product better,
> > and alas get more satisfied customers. 
> 
> That's how the gpc developers/maintainers feel too, I think.

Correct, too.  With the only difference that we don't get money for our
work on GPC.  (Instead we will get our dream compiler.:)

> > As far as i can remember (this might be wrong) GNU pascal dont have
> > oop. 
> 
> By now, AFAIK, gpc has (nearly) the same OOP as TP, but doesn't implement the
> Object Pascal (not-yet-)standard.

Correct.  It has the "Borland Pascal 7.0 with Object" standard.  Only the
"private" directive and "dynamic methods" (Function Foo; virtual 1234;)
are still missing.

> > >To each his own.  If you want overloading and procedures with variable number of
> > >parameters, then check out languages that support them.  
> > Belive me, I have .. But I really dont like C. Its so.. what should I
> > say..  pee->(wee&&) .. I just dont like it :)
> 
> I don't think that's valid in C (provided there's anything that's not valid in
> C - not sure if there is... :-> ), but I know what you mean. I'd also prefer
> to have the Pascal syntax and yet many of the other features.

I agree - including the try with C++.  That's why I am working on GPC.

However, function and oparator overloading are not new to Pascal.
At least the PXSC standard has this feature.  (You *need* it for
scientific programming!)  Unfortunately I have never seen a working
PXSC compiler, only a book with the standard specifications ...

> > I think that would be a bit to much trouble really. I was just
> > presenting the idea to get a feeling of  other people's thoughts on
> > the matter.
> 
> If you're serious about it, join the gpc mailing list.
> I'll post a copy of this message to the list, since it's quite much about gpc.

:-)

> > Writeln, reset, and a whole bunch of others allready support it. it's
> > just not any way for the -user- to define procedures like that. 
> > 
> > and that is a shame . :) 
> 
> But of course, it's much more difficult to provide a way for the user to
> declare and implement such procedures than to just allow some specially
> handled procedures like Writeln.

Correct.  But it seems that VAX Pascal has solved this problem.  We should
have a look at their solution.

> > [...]

> > One, not very good, would be to require VAR types in function
> > overloading (thats what you called it, right?), like this:
> >         function f(var nr:byte);
> > 
> > This would remove the problem all together, but its not a very
> > flexible way of doing it.
> 
> Quite restricting...

But it already works, in GPC and in Borland Pascal:  Use an untyped
formal `Var' parameter, and use `absolute' variables to access it.
(See my other mail.)

> >As a side note: Doesn't FPK support function overloading?
> [...]
> AME replied: 
> > Either FPK or GNU, I can't remember which. I can't even remember if it
> > was fully implemented.

Implemented in FPK, planned for GNU.

> AFAIK, gpc supports part of the PCSX (Pascal scientific extensions) standard.
> I don't know this standard, and haven't used these extensions, but I think
> there is some kind of overloading. You might want to find out if there were
> any ambiguity problems involved, and how they were solved.

Operator overloading is implemented in GPC; function overloading is
defined in PXSC, planned for GPC.

> To me the point is that the extensions, however implemented, must still allow
> Pascal's strong type checking. (In this example, the type checking was
> annulled by assembler code, type casts or (unnecessarily) untyped pointers,
> I'd guess from what I know about TV.)

Correct.  In TV, they unnecessarily used untyped pointers.  Correct use
of a *carefully* implemented function overloading scheme would not cause
this trouble.

> Sure. And gpc already has compiler switches to ensure that certain features
> are [not] used. All the extensions discussed here would be object to these
> (or additional) switches, too.

Correct.

(I see there is not much need for me to join the discussion directly. ;-)

> At last, I've got some suggestions for the varargs problem, too:
> [...]

Looks nice, but let's first see how VAX Pascal solved the problem.

> Alternatively, it would suffice to allow "array expressions" like:
> 
> procedure varnumargs(p:array of integer); begin ... end;
> 
> var a,b,c:integer;
> begin
>  varnumargs( (a,b,c,2,c-b,27) )
>             {^^^^^^^^^^^^^^^^ array declaration as in a "typed const"}
> end.

This I don't understand.  Parameters like "Var p: array of Integers" *do*
work in GPC (note the `Var'; lower bound is set to zero, upper remains
unchecked; Extended Pascal's schemas will provide a better way to achive
the same functionality.)

> 2. Unknown type of an argument
> 
> Ok, there are untypes arguments in TP, but they don't allow for any type
> checking when used, so they're not suited here. Furthermore, the procedure
> doesn't get any information about the type, so this information would have
> to be passed separately (as in the printf format string in C), which is not
> acceptable.
> 
> So the type must be passed internally, and there must be a way for the
> procedure to check the type, and to access the parameter as its real type.

Objects.

> I could imagine something like the following:
> [...]
> (This syntax is only tentative, it doesn't have to be called IFTYPE and
> CASETYPE.)

Perhaps a good idea, but the type would have to be passed as an (implicit
or explicit) additional parameter anyway, and you can do the cast using
`absolute' variables - which already work.  I am not sure whether it is
worth the effort and the loss of compatibility to other compilers to
implement `iftype' and `casetype'.

> Of course, the SizeOf function would work on a and return the actual size.
> [...]
> One has to investigate if and how this is possible (considering multiple, 
> possibly nested IFTYPEs/CASETYPEs)...

Much work.  Probably too much, sorry ...

> Another idea is whether it is possible and/or useful to compare types of 
> different arguments:
> 
> procedure equal(const a,b);
> begin
>   IFTYPE a,b then {Compare SizeOf(a) bytes at @a and @b}
>   else Error('Comparison of different types not allowed!')
>   {^^^ or again, rather a compiler error...}
> end;

This I don't understand.

> It also seems useful to declare local variables of the same type as an
> argument:
> 
> procedure swap(var a,b);
> var temp:TYPEOF(a);
> begin
>   IFTYPE a,b then begin temp:=a;a:=b;b:=temp end
>   else Error('Swapping different types not allowed!') {see above}
> end;
> 
> (I think, Extended Pascal (gpc???) has some kind of type inquiry, but probably
> only for known types. Anyway, this one could, of course, use the same syntax
> as EP (it's probably not the syntax above, since I don't know the EP syntax).)

It's

    Var
      temp: type of a;

AFAIK, it works only for known types.  But I'm not (yet) an EP expert.

> Concerning the implementation, I'd say that for each "vartype" parameter an
> additional (invisible) parameter is passed that describes the type uniquely.
> Since the compiler has to keep track of all the types somehow anyway, it
> shouldn't be hard to generate a unique number for each type.

It *is* hard.  Consider a large project with many Units/Modules which are
compiled separately ...

> Many ideas... many problems... much to do...

Correct!

> This message is distributed under the terms of the GNU General Public License.
> The license can be retrieved from many ftp and www sites, e.g. from:
> ftp://sunsite.unc.edu/pub/gnu/COPYING
> http://www.mi.uni-erlangen.de/~heckenb/COPYING
> If you can't get this file, mail me, and I'll send you a copy.

:-)

Greetings,

    Peter

  Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
       maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)