Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!metro!seagoon.newcastle.edu.au!wombat.newcastle.edu.au!eepjm From: eepjm@wombat.newcastle.edu.au (Peter Moylan) Newsgroups: comp.lang.modula2 Subject: Re: Missing from Modula-2 Message-ID: <1991Jun19.144407.1@wombat.newcastle.edu.au> Date: 19 Jun 91 04:44:07 GMT References: Sender: news@neddy.newcastle.edu.au Distribution: comp Organization: University of Newcastle, AUSTRALIA Lines: 51 In article , iwm@doc.ic.ac.uk (Ian Moor) writes: > Why, if the function f returns a pointer can I not write: > > f(x)^.field := ... > > instead of: > > temporary := f(x); > temporary^.field := ... > Many years ago I wrote a compiler for a language called SGL which did allow things like this. You could also write assignment statements like @@@(f(x) + 2*@(#y-5)) = 3 - $ [Explanation: '@' is a prefix version of the Modula-2 '^', '#' means "address of", and '$' means "the value of the thing on the left side of the assignment.] Overall, SGL had a power and expressiveness similar to that of C. (At the time I first designed SGL, I was unaware of the existence of C, Pascal had not yet been invented, and I wanted something better than Fortran.) I no longer use it because of its primitive nature - it became obsolete at about the same time as C did. ;-) Anyway, based on this experience I can suggest several reasons for omitting such a feature from a high-level language: - to allow it, you have to modify the conventional grammar in such a way as to permit baroque constructs like my example above. Clarity then suffers. It's no good warning users not to use unclear constructs to excess. If something's permitted, it will be used, and the messier it is the more it will be used. If you doubt this last statement, just look at the work of a typical C or APL programmer. - you have to worry about side-effects; for example, what are the semantics of f(x)^.y := x when x is a VAR parameter whose value might be altered by the function invocation? Sure, you can develop rules, but those rules tend to complicate the language description so much that you lose the "economy of concept" idea which is so important in Modula-2. They also get in the way of code optimization. Note, by the way, that difficulty of compilation is not really an issue here. The proposed construct would add very little to the complexity of the compiler. The real issue, as I see it, lies in keeping the programmer's view of the language sufficiently clean that the probability of programming error is kept acceptably low. Peter Moylan eepjm@wombat.newcastle.edu.au