Gpc March 1997

gpc@gnu.de

17 participants
53 discussions

Re: Apparent gpc bug
by Peter Gerwinski 14 Mar '97

14 Mar '97

According to Stephen Lindholm: > gpc barfs on this program.[...] > > [...] > > type > TLittleChar = 'A' .. 'C'; Ah - I see. Okay, it's easy to fix: In gpc-parse.y do the following: 8< ---------------------------------------------------------------------------- gpc-parse.y gpc/gpc-parse.y --- gpc-970226/gpc-parse.y Thu Feb 27 11:34:07 1997 +++ gpc/gpc-parse.y Wed Mar 12 19:36:39 1997 @@ -1568,6 +1568,8 @@ subrange_type : constant TWODOTS expression { + $1 = string_may_be_char ($1); + $3 = string_may_be_char ($3); if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); 8< ---------------------------------------------------------------------------- The bug will be corrected in the next alpha release, too. Thanks for the report! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Pascal's identity
by Peter Gerwinski 14 Mar '97

14 Mar '97

Hi, everybody! Let me just tell you my thoughts about Pascal's identity and the future of GPC. My point is: I need a working GPC as soon as possible to make a living. At the moment, I am programming mostly in Borland Pascal 7.0. But BP7 has no future outside Windows 95, so I want to switch to GPC completely. To me, features which make my programs evolve faster have highest priority. (Of course, actual bug fixes have highest priority, too.) It is desirable to comply to existing standards, but I don't consider this compliance as an end in itself - at least concerning Pascal where very few people know the standard and even fewer are content with it. For example I continue to use BP-style Units although there are EP Modules. I find Units better. (BTW, Units have not been invented by Borland, but they are part of the UCSD Pascal standard.) OTOH, I see the advantages of Schema types, so I want to have them before I start porting my major application programs to GPC (i.e. continue with BO5). For some standard features I don't see their use, but they are hard to implement, so I assign them quite a low priority. This especially applies to some error messages required by the standard, e.g. for unresolved `case'. In case somebody else wants to take care of such things, I would be glad to help him or her to get into GPC hacking. So completing the standard/s does *not* have higher priority to me than to create GPC extensions. (However I will try to do both.) Concerning the purity of Pascal I agree that there are *some* extensions which should at least be warned about unless you explicitly enable them (with (*$X+*) - or with the command-line option "--extended-syntax"). I am speaking of those extensions which could become a trap for beginners. For example, function overloading should be disabled by default because it might confuse a beginner who does not yet know enough about parameter lists. OTOH, I don't see any need for disabling operator overloading by default because you cannot overload an operator unintentionally. For the case somebody does not like GPC to support a mixture of several Pascal dialects, there exist options which enforce a certain standard, including all misfeatures, as far as implemented. For example, the "--borland-pascal" option does not only disable EP Modules, but also the warning about assignment to typed constants. OTOH, the "--extended-pascal" option disables UCSD Units. Both options disable operator overloading. I hope this helps to clarify what direction I intend GPC to go. Suggestions are welcome; actual help to implement things is even more welcome. ;-) Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

unable to process using elf(3E) libraries
by David Lewis 14 Mar '97

14 Mar '97

I am trying to get gpc up and running on a Sun Sparc 4 running Solaris 2.4 Whatever the source I try to compile and link, I get link errors : % gpc -o hello hello.pas collect2: ld returned 1 exit status ld: fatal: file hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: File processing errors. No output written to hello % (I installed collect2 as indicated in the FAQ) Another strange thing is that I am obliged to copy a whole load of gcc objects (crt1.o; crtbegin.o; crtend.o; crti.o; crtn.o) into my current directory to avoid additional problems. Without these objects being present I get : % gpc -o hello hello.pas collect2: ld returned 1 exit status ld: fatal: file crt1.o: cannot open file; errno=2 ld: fatal: file crti.o: cannot open file; errno=2 ld: fatal: file crtbegin.o: cannot open file; errno=2 ld: fatal: file hello.pas: unknown type, unable to process using elf(3E) libraries ld: fatal: file crtend.o: cannot open file; errno=2 ld: fatal: file crtn.o: cannot open file; errno=2 ld: fatal: File processing errors. No output written to hello % Is this a bug ? If not, I should be grateful if anybody could tell me where in the installation I've gone wrong. With my thanks, David Lewis Systems engineer UTC - France

1 0

Re: varargs in GPC
by Peter Gerwinski 14 Mar '97

14 Mar '97

> I thought that GPC did not support varargs. In fact, I > was hoping that it would support the VAX Pascal syntax for > doing so. What is the status of variable arguments for GPC? It does support `ellipsis' parameters to call functions with varargs written in C. We have not (yet!;) implemented a portable mechanism to access them. IMHO, it would be reasonable to implement the VAX Pascal syntax into GPC rather than inventing a new method. If you tell me about the VAX Pascal syntax for accessing varargs, it will enable me to do this. BTW, there is yet another Pascal standard definition, PXSC, which supports overloading of procedures and functions. In that dialect you can, for instance, implement an exponential function for real, rational, complex numbers, quaternions and matrices, and all of them are called `exp'. This covers many applications of varargs, is implemented in FPK Pascal and is planned for GNU Pascal, too. A way to pass a constant number of arguments of variable types is to use UCSD (or Borland) Pascal's untyped `Var' parameters in combination with Borland Pascal's `absolute' clauses: Procedure Foo ( Var Bar ); Var BarChar: Char absolute bar; BarInt: Integer absolute bar; BarString: String ( 80 ) absolute bar; ... However: Please help me to with VAX Pascal vararg syntax! I don't have a VAX, and I don't have the money to buy one, so I need example programs with descriptions what they are intended to do, etc. (you know). Greetings, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

2 1

Re: Variable number of parameters
by Berend de Boer 14 Mar '97

14 Mar '97

I think if you really want var args, function overloading, powerfull preprocessors, etc. program in C or C++. Don't fool with Pascal's identity. And I think 99.9% of what people want with varargs can be quite cleanly implemented with Borland's open array and with variant arrays (boy, I need to use them sometimes, but it's quite bad to let the customer find typechecking bugs...) Groetjes, Berend.

2 1

Re: varargs in GPC
by Frank Heckenbach 13 Mar '97

13 Mar '97

Berend de Boer wrote: > I think if you really want var args, function overloading, powerfull > preprocessors, etc. program in C or C++. > Don't fool with Pascal's identity. I don't agree. I don't think things like varargs, overloading etc. are inconsistent with Pascal's identity if properly implemented. What is part of its identity, IMHO, is e.g. strict typing and type checking at compile time. Of course, this is an issue with varargs and overloading and is has to be carefully considered, so that all type checks can be made at compile time and no ambiguities will arise. These features can make programming easier and more comfortable (if used properly, of course), so see no reason no to have them (except not to have the time to implement them...) OTOH, preprocessors, AFAIK, are not part of any language at all, as the same preprocessor can be used for C and Pascal. However, C needs a preprocessor because certain features (constants, modularisation) are not present in the language itself. I think a (sufficiently sophisticated) Pascal should not (or at least very rarely) need a preprocessor, so in this regard I agree with you. > And I think 99.9% of what people want with varargs can be quite cleanly > implemented with Borland's open array and with variant arrays ... and with schema types when they're there.<F2> > (boy, I need to > use them sometimes, but it's quite bad to let the customer find typechecking > bugs...) I'm not completely sure what you mean here, but it sounds like a case where typing errors are not detectect at compile time but at run time. Exactly this is what I want to prevent by the mechanisms I suggested - mainly because I'm not very content with Borland's open arrays and absolute variables. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Re: varargs in GPC
by Frank Heckenbach 13 Mar '97

13 Mar '97

Peter Gerwinski wrote (in several postings): > BTW, there is yet another Pascal standard definition, PXSC, which supports > overloading of procedures and functions. In that dialect you can, for > instance, implement an exponential function for real, rational, complex > numbers, quaternions and matrices, and all of them are called `exp'. This > covers many applications of varargs, is implemented in FPK Pascal and is > planned for GNU Pascal, too. I agree that most of the time you can do with overloading instead of varargs. Varargs are really needed only very rarely, I think, e.g. in things like Read[ln] and Write[ln] and variants like ReadStr, WriteStr, ... BTW (a bit off-topic for the subject): Is there a meachnism like TP's "text file device drivers" in gpc, i.e. a means of (roughly speaking) assigning a Text "file" variable with a input/output routine, so that the main program can use Write[ln] etc. comfortably, and the routine gets the data in a raw form (a buffer and its length) (and similar for input) - so the routine would be relatively easy to implement but flexible to use? If there's not, is it realistic to hope fur such a thing in gpc? Note, I don't mean to duplicate Borland's way of doing it (which I find quite clumsy), but any way at all. It doesn't even have to be a Text variable, but if not, one would need another variant of Read[ln], Write[ln]. Such a meachnism would eleminate many of the (few) needs for varargs. I'm thinking of things like text output on a graphics screen. In TP (and also in the Graph unit of the BGI2GRX package) there's only an "OutText" procedure that takes a string. (This is reasonable since a graphics unit should not have to worry about formatting output.) If one wants to write a number, one has to manually convert it to a string before outputting. A mechanism like above could simplify this. > A way to pass a constant number of arguments of variable types is to use > UCSD (or Borland) Pascal's untyped `Var' parameters in combination with > Borland Pascal's `absolute' clauses: > > Procedure Foo ( Var Bar ); > > Var > BarChar: Char absolute bar; > BarInt: Integer absolute bar; > BarString: String ( 80 ) absolute bar; > > ... I don't like this! (Actually, I myself use type casts instead of absolute variables, but I like them just a little.) The reason is simply that Pascal's type checking is annulled. (The TV example in the other posting was a good example of what can happen...) One can use it if there's nothing better, but, IMHO, this is no real Pascal (because Pascal is strictly typed). Therefore I'd still prefer having a mechanism like the "IFTYPE" I suggested. > However: Please help me to with VAX Pascal vararg syntax! I don't have > a VAX, and I don't have the money to buy one, so I need example programs > with descriptions what they are intended to do, etc. (you know). I agree. If there's already a varargs syntax (and if it enables type checking - unlike C's varargs), gpc should try to be compatible. > Don't forget EP's Schema types. ;-) I am prepared to put them into GPC, > but it will take some while, sorry. Indeed, schema types can reduce the need for overloading, I suppose (I never used them - how should I?). BTW (maybe I'm opening up another can of worms...): Can the "parameters" (is it called that?) of a schema type only be ordinal values like array indices, or could they be types themselves? IOW: Would it be possible to implement a general list (tree, dynamic array, whatever) as a schema. As I think about it, I don't see any principal obstacle to do this, using some of the ideas I had on variable types of procedure parameters. I think this could be a *great* simplification for many programs. (Who hasn't implemented the same concepts, slightly differently, again and again?) > I agree; however Borland has had something like this ("Form" procedure) in > Turbo87 3.0 and something similar in Turbo Vision ("FormatStr" procedure), And I don't like the FormatStr procedure, because 1. of missing type security (see above, concerning absolute variables) 2. it's very clumsy to use, IMHO. (To get a formatted string, one has to declare an array, assign values to each field, and call FormatStr - all of which a C programmer can do with a single call to sprintf.) > and you can call C functions like "printf" from GPC using the declaration > > Function Printf ( format: CString; ... ): Integer; > > (Yes, with three dots.) Easier to use, but again no type checking, and besides, the point in Pascal programming isn't to call C functions... :-) > > > 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.:) He wasn't talking about money, but of satisfied customers. That's not the same at all - just look at M$! > Correct. It has the "Borland Pascal 7.0 with Object" standard. Only the > "private" directive If you do it, please do it not in the Borland way (private methods visible in the whole unit - or module here), but more reasonable as visible only for the declaring object type. A "protected" directive (visible to the declaring type and all sub-types of it) would be a good idea, too. Maybe one would also need something like C++'s "friend" (not sure if this is really necessary). > and "dynamic methods" (Function Foo; virtual 1234;) > are still missing. Up to now, I've seen only one use for them, namely Borland's way of implementing message/event handlers in TV/OWL. I'm not convinced that this is really a good thing (all it saves seems to be a case statement or a loop through a constant array or list) - I think it could be done better if one allowed "class" variables/constants, i.e. variables/constants that are the same for all objects of a given type. Here, the class constants would be tables or lists of the message IDs together with their handlers, and "dynamic methods" might not be needed at all. (If there are other applications to them, please tell me!) Class variables/constants, OTOH, are a feature found in several OOP languages, and have more uses. (I'd have liked to have them myself sometimes). > However, function and oparator overloading are not new to Pascal. > At least the PXSC standard has this feature. (You *need* it for > scientific programming!) I have to support this! Especially for operators. > Unfortunately I have never seen a working > PXSC compiler, only a book with the standard specifications ... That's the problem with standards, they just don't compile any program... ;-) > 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.) See above, why I don't like it. IMHO, a real untyped parameter (usually together with a Size value) should be used only if the type doesn't matter at all (such as raw memory copy/compare, file read/write), and not as a substitute where the language provides no way for a "correct" declaration. > > 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. What I meant here is a way of declaring an "array expression" (similar for records), i.e. a way of constructing an array in an expression, e.g.: var v:record s:string; a:array[1..3] of integer end; begin v:=('H.W.',(1,2,3)) end. This is not strictly related to varargs and might not be too easy to implement, but can be useful sometimes, too. I'm just collecting ideas here. > Parameters like "Var p: array of Integers" *do* > work in GPC (note the `Var'; Is there any reason why this doesn't work with value parameters? In TP, it does, AFAIR. > lower bound is set to zero, BTW: Is this reasonable? Borland does it this way, but IMHO, it would be more Pascal-ish to pass the bounds together with the parameter and... > upper remains unchecked; ...to provide something like Borland's High and Low pseudo-functions (to get the actual bounds within the procedure). High and Low should work on any array (not only open array parameters), and on ordinal types (giving the minimum and maximum value), IOW with "type a=array[r] of t;" it would hold low(a)=low(r). > Extended Pascal's schemas will provide a better way to achive > the same functionality.) Yes; and in this case perhaps also conformant arrays (I don't know them)? > > 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. Yes, I was thinking of OOP, too, when I wrote it, but unless Pascal is going to be a completely OOP language in the future (which I don't think), a non-OOP way will be useful. As long as only a single parameter is concerned, you can usually achieve the same with overloading, but when more parameters can be of variable type, the number of needed overloads would increase dramatically... > > 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, Yes, the type has to be passed, but I see no (sensible) way to use the type except to compare it to a known type (my "IFTYPE") or to another unknown type (my variant on "IFTYPE"). > 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'. Sure it will be a lot of work, but I think compatibility to other compilers is not the point here. There are already many extensions in gpc (e.g. parts of EP *and* TP, or gpc's own extensions), that are not supported by any other compiler. And, if we find a good mechanism, it might be part of a standard sometime... > > [About the compiler catching type errors in variable types] > > One has to investigate if and how this is possible (considering multiple, > > possibly nested IFTYPEs/CASETYPEs)... > > Much work. Probably too much, sorry ... As I think of it, probably yes, but it might be possible to specify the allowed types in the declaration, like: procedure p(v:(Integer,String,Boolean)); Then the compiler can make sure that no other types are passed. This would be similar to an overloaded procedure, but as I said above, useful if more than one parameter is involved. Of course, there could also be parameters with no type restrictions, where the procedure would implement some default behaviour for types it doesn't know, treating it as unstructured data of known length (SizeOf still works). > > 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. What I meat is that IFTYPE could not only compare the type of one unknown parameter to a know type (e.g. Integer), but also compare the types of two unknown parameters. For procedures like (raw) compare or swap, all the procedure has to know is the size and that the types match. Revised delcaration: procedure equal(const a;const b:type of a); Why not... > AFAIK, it works only for known types. Probably, or are there any unknown types in EP at all (in parameters, schema types, whatever)? > > 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 ... No problem: Unique_Type_ID = Unique_Module_ID * C + Unique_Type_ID_Within_Module where C is larger than the biggest possible/reaonable number of types whithin a module, in the worst case $100000000, but that might be a little too much. Or: Unique_Type_ID = Module_Offset + Unique_Type_ID_Within_Module where Module_Offset of a module is calculated just before linking as the sum of the number of Type_IDs in all modules before the one considered, given any ordering of the modules. Only types that are actually used for variable type parameters, or that appear in an interface, need type IDs. Of course, any use of these IDs would have to be partially (the Unique_Module_ID/Module_Offset part) resolved at link time - I hope this is possible with the usual linkers - or if not, at run time by use of an additional variable per module that contains its Module_ID/_Offset)... -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

1 0

Apparent gpc bug
by Stephen Lindholm 12 Mar '97

12 Mar '97

gpc barfs on this program. This is a small clip of a larger program, so I suppose it could be trimmed some more, but it demonstrates the problem. It tells me that the subrange bounds are not of the same type. program temp (input, output); type TLittleChar = 'A' .. 'C'; begin writeln; end.

1 0

Re: Variable number of parameters
by Peter Gerwinski 11 Mar '97

11 Mar '97

According to Berend de Boer: > I think if you really want var args, function overloading, powerfull > preprocessors, etc. program in C or C++. Function overloading is in FPK Pascal and in the PXSC standard. PXSC also defines operator overloading which is supported by GPC, too. (Has anybody out there ever seen a working PXSC compiler? I know about the standard definition, but ... ???) > Don't fool with Pascal's identity. With the switch `--extended-pascal --pedantic-errors' everything which exceeds the Extended Pascal standard is reported as an error. You are never forced to use existing extensions. > And I think 99.9% of what people want with varargs can be quite cleanly > implemented with Borland's open array and with variant arrays (boy, I need to > use them sometimes, but it's quite bad to let the customer find typechecking > bugs...) Don't forget EP's Schema types. ;-) I am prepared to put them into GPC, but it will take some while, sorry. BTW, what about conformant arrays? Do they work with GPC, or are there still bugs? Somebody out there to write some documentation notes about conformant arrays to tell the poor Borland Pascal programmers (like me;) how to use them? Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Variable number of parameters
by Peter Gerwinski 11 Mar '97

11 Mar '97

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.) > 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(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc March 1997