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 <dreaming>. 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.)
- 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]