iwm@doc.ic.ac.uk (Ian Moor) (06/18/91)
Why, if the function f returns a pointer can I not write:
f(x)^.field := ...
instead of:
temporary := f(x);
temporary^.field := ...
o.k so the compiler has to allocate a temporary location. I notice that
the DECWRL compiler will cope with this by the way.
--
Ian W Moor
Internet: iwm@doc.ic.ac.uk
JANET: iwm@uk.ac.ic.doc
Department of Computing, That which you call a crime when one man does it,
Imperial College. you call government when done by many.
180 Queensgate
London SW7 UK. warwick@cs.uq.oz.au (Warwick Allison) (06/19/91)
>Why, if the function f returns a pointer can I not write: > > f(x)^.field := ... I've always wondered this too. All I can guess is that it make the parser simpler not to allow both: Statement ::= Designator "(" ActualParameters ")" and Designator ::= Designator "(" ActualParameters ")" where Designator ::= Designator "^" Designator ::= Designator "[" ExprList "]" Designator ::= Designator "." Field Designator ::= QualifiedIdentifier That doesn't look LALR(1), but I'm not sure. Then again, M2 allows the syntax QualifiedIdentifier ::= Identifier { "." QualifiedIdentifier } to screw up Designators (The semantic class of Identifier - ModuleName or Variable is needed). Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
eepjm@wombat.newcastle.edu.au (Peter Moylan) (06/19/91)
In article <IWM.91Jun18101949@swan.doc.ic.ac.uk>, 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