[M3devel] operator overloading?

[Henning Thielemann]

Jay K wrote:
> Is it really so difficult to add operator overloading to the language?
> 
>  From a user's point of view, I know it is very useful in certain 
> situations.

I have a dejavu. This must have been discussed here several times. I 
remember Rodney Bates' coining "syntactic heroin".

"Operator overloading" is actually two extensions:

1. Allowing to write functions in an infix way, preferably using symbols 
instead of letters.
2. Allow to reuse the same function name depending on context.


The first issue is a syntactic one, but a hard one. For infix operators 
you must define associativity and precedence. If you define it within a 
module, the parser must adapt to the precedence rules, as it parses 
them. Alternatively you could define precedence in different syntax 
descriptions files using a custom language - also bad because you need a 
new language and management for a new kind of source file. You can no 
longer just run m3pp from within your editor on a draft of your program, 
because formatting also depends on precedences. You rather want 
expressions formatted as

    long_expresssion +
        other_long_expression * last_long_expression

instead of

    long_expresssion + other_long_expression
        * last_long_expression

In Haskell precedences are defined by numbers from 0 to 9 and you can 
declare left-, right- and no associativity. That does not scale well. In 
PROLOG you have numeric precedences in the range 1-1000 or so, and a 
little more fine grained associativity rules. In Agda you have numeric 
precedences also in a quite large range (1-1000 or so) and mixfix 
notation, that is,  a function with three arguments can be written 
according to a pattern like (if _ then _ else _). I still think that the 
most natural way to define precedences is by relations like "'-' shall 
bind as much as '+', whereas '*' should bind stronger than '+'". Those 
numeric precedences are to maintain, just like line numbers in old BASICs.


The second issue is the resolution of ambiguous names. Modula-3 has no 
support for this, currently. Haskell solves this cleanly using 'type 
classes', that despite the name do not have much in common with 
object-oriented classes. But these type classes are based on 
Hindley-Milner type system that allows e.g. to assert that two operands 
have the same type, another thing that Modula-3 does not have and that 
cannot easily be added.

In short, I think both infix or mixfix notation and resolution of 
ambiguous names require fundamental changes to Modula-3. If they are 
essential for you, it might be easier for you to use a language that 
supports them well.

-- 
Mit freundlichen Gruessen
Henning Thielemann

Viele Gruesse
Henning

Martin-Luther-Universitaet Halle-Wittenberg, Institut fuer Informatik

Tel. +49 - 345 - 55 24773
Fax  +49 - 345 - 55 27333