Path: utzoo!attcan!uunet!husc6!wuarchive!cs.utexas.edu!rice!titan.rice.edu!preston From: preston@titan.rice.edu (Preston Briggs) Newsgroups: comp.lang.modula2 Subject: Re: Does Modula-2 have operator overloading? Message-ID: <10275@brazos.Rice.edu> Date: 26 Jul 90 20:16:53 GMT References: Sender: root@rice.edu Organization: Rice University, Houston Lines: 41 In article Modula2 List writes: >On Thu, 26 Jul 90 16:01:58 GMT Preston Briggs said: >>*I* certainly don't want to maintain programs that redefine >>precedence of existing operators. The other features sound > >You have a good point there. The reason I included existing >operators was to prevent 'wrapping' and allow such things as the >definition of a CARDINAL (operator) INTEGER operation >(for convenience). I think that defining the precedence of operators >is a good compliment to op overloading. I could live without >redefining the existing operators. The approach used by Clu (or at least explain in the reference manual) is pretty cool. They define many operators and their precedence and associativity (I don't know about commutivity). I believe these properties are fixed, as is the set of operators. Therefore, you and I and the parser can look at the program and all parse it identically. However, things get more interesting. "x + y" is transformed into the function invocation "sometype$plus(x, y)" where sometype is the type of x and $ is the selection symbol. This happens with all the operators, including "." and "[ ... ]". So it's fairly easy to define something like "+" as string concatenation. You add a function "plus" to the cluster defining strings and the parser will fix you up. I should apologize to Clu hackers for mangling the explanation of their language! My other arguments related to difficulties in defining the language. I still hold that it's a tough job. It's quite difficult to get a set of features to work together well. I can pick nits over lots of unimportant things, but getting the big picture right is probably harder than implementation. -- Preston Briggs looking for the great leap forward preston@titan.rice.edu