🚀 go-pugleaf

On Wed, 5 Jun 91 08:21:25 CDT Mike Dorman said:
>
>Someone opined in a Dr. Dobbs Journal many years back, that one obvious
>addition to Modula-2 (or any other language, for that matter) is a keyword
>like OPERATOR, or something, which would let you define thingies which you
>use to perform operations on variables, like **.
>
Add concepts (when necessary), not keywords :-)

>The only problem I see is that it would either have to take into account
>all possible variable types, or be variable-type-specific.  It would be
>quite nice to be able to write a + operator for concatenating strings,
>and stuff like that.
There are much more problems in this area:
- If you allow arbitrary operators, the scanner must be changed at
  run time, e.g. to recognize "**" after it has been defined. This
  would slow down lexical analysis and make the grammar context
  sensitive even on the lexical level *shudder*.
- A second problem in this case would be how to define precedence.
  Fixed (and probably equal) precedence of user-defined operators
  would be counter-intuitive (imagine "**" with lower precedence than
  "+"). User-defined precedence (perhaps like Prolog's precedence
  numbers) would make nearly every common parsing technique unworkable;
  and it would cause problems when selveral unrelated modules are used
  by one client module.
  Parsing precedence grammars (whether precedence is dynamic or not)
  is terrible.
If you restrict it to additional meanings for existing operators,
what you are proposing is just overloading, which does also have
several problems:
- It forces you to use unqualified imports, which I consider just
  unacceptable in large projects. I want to see on each and every
  occurence of a name where it comes from, instead of referring to
  many tenth of lines of imports. Reminds me to the tons of include
  files for X11 programs in C :-(
- Overloading resolution adds considerable complexity to the compiler,
  including nasty scope resolution problems.

Of course none of the problems is unsolvable, but all "solutions" I've
seen so far (and there are many) are unusable, difficult to understand
or difficult to implement, usually all three. Therefore I'd argue not
to have general overloading is better.

I consider the "effort" typing something like "RealMath.Power(...") or
"ComplexMath.Power(...)" etc. not too high a price for clarity.
Of course, a powerful editor (like Emacs) reduces much of the typing
overhead :-)

Marc Wachowitz
X903@DMAFHT1.BITNET