Up to now, GPC supports overloading of binary operators like `+' and user-defined operators such as `Foo', but also only as binary operators. I propose to extend and generalize this mechanism, e.g. to unary operators.
Besides the usual unary operators like `+' and `-', you can define your address operator as `@' (BP compatible) or `&' (like in C) or whatever you prefer. Also other C operators like `++' can then be easily defined without the need to have them built-in.
A special case would be the `^' operator since it's used both prefix (in pointer type definitions) and postfix (in pointer dereferences). I'm still thinking about the syntax for the operator declarations, but `operator ^ (...)' and `^ operator (...)' would seem to be the most obvious choices.
Some time ago, someone asked for backslash interpretation in string literals. Redefining the `'' (i.e., single quote) operator would make this easy. Also, the BP operators `#' and `^' (as in `^C') for character constants could be defined in a similar way, without messing up the syntax when they're built in.
The same applies to BP's `$' for hex integer constants. But, OTOH, friends of the C syntax could define `0x' for hex and, if they like, they could even define the `0' operator for octal constants.
Those who've always complained about Pascal's verbosity, could finally define the `{' and `}' operators as `begin' and `end' (preferably after defining the comment operator to `(*', `//' or whatever they prefer). And those who would prefer `;' as a statment terminator (as in C) instead of a statment separator can simply redefine this operator.
Back to binary operators, apart from `:=' (as recently requested), also `,' would be a very interesting one. We could have all the interesting properties of this C operator in Pascal.
Overloading `[' (for self-made arrays) and `.' (for records/objects) would work like in C++, of course, and can probably be used to implement Delphi-compatible object properties without further compiler support. Perhaps we can even define `class' as an operator (that inherits from `object', and `^') to provide for classes with implicit references.
The `_' operator could be defined to be rejected in identifiers in classic Pascal (so we don't need the explicit compiler checks we have now), whereas, e.g., international letters can be allowed in identifiers by defining them as new operators.
Overloading the `if' operator could be useful to make a new conditional syntax -- perhaps with `endif' to avoid problems with dangling `else' etc.
By overloading `const' to `var' for typed arguments, BP's "typed constants" could be supported without any contortions in the compiler.
Finally, overloading the `operator' operator seems very interesting, but I'll have to work out the details.
Frank
Uh...
April Fools?
This is a bit on the extreme side, and I hope you realize how much work you have cut out for you if you intend to accomplish all of that. Some of it is reasonable, but other things...
It just isn't a Pascal compiler anymore; it's a generic compiler which defaults to a Pascal syntax if all else is lacking. You could use this overloading mechanism to turn it into a (yuck) C compiler!
--- Frank Heckenbach frank@g-n-u.de wrote:
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com
Actually, overloading of unary operators might be a good idea (leaving apart the rest of the joke :)
Sure, then we can do negation with '+' and square root with '-'!
(another joke, but seriously, if we allow overloading of binary operators, then why not unary ones... but I hardly think overloading the ';' operator is reasonable. There IS a limit.)
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com
Frank D. Engel, Jr. wrote:
I think currently we have 4 unary operators: `+', `-', `not', `@'.
Overloading `@' (BP style address operator) would seem strange to me -- basically because the built-in meaning already accepts all types (as "reference parameters").
Overloading `+' and `-' could be useful (e.g., when implementing your own vector arithmetic etc.), and perhaps `not' as well.
However, overloading `-' for Integers would mean that `-42' gets a different meaning.
New user-defined unary operators would probably cause parsing problems (since an identifier (operator) can occur where other identifiers (variables, constants, functions etc.) are also allowed), though they might be solvable with some effort ...
Frank
On Wed, Apr 02, 2003 at 08:53:37PM +0200, Frank Heckenbach wrote:
Wouldn't it also clash with the ISO meaning of `@' ?
Overloading `+' and `-' could be useful (e.g., when implementing your own vector arithmetic etc.), and perhaps `not' as well.
That's what I had in mind.
Apart from the parentheses, new user-defined unary operators are just about the same as unary functions, so they are probably not worth the trouble.
Emil
Emil Jerabek wrote:
I don't think so. In ISO `@' (equivalent to `^') can be used in a type-definition (no conflict here) and as a postfix operator (pointer dereference). If there was a conflict with a user-defined operator, it would also be against the BP (prefix) operator. But still I wouldn't like to let it be overloaded.
Maybe I'll implement it sometime (or perhaps someone else would like to do it?) ...
Frank
Frank Heckenbach wrote:
Luckily I took a look at some other answers before exploding. Since I am reading this at the end of the 2nd, rather than on 2002-4-1 when sent, and am naturally slow, it took a while to catch on.