Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!DMAFHT1.BITNET!X903 From: X903@DMAFHT1.BITNET (Marc Wachowitz) Newsgroups: comp.lang.modula2 Subject: Re: OPERATOR (was: Why no ** operator in Modula2?) Message-ID: Date: 6 Jun 91 09:05:11 GMT References: Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 50 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