🚀 go-pugleaf

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