Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!pa.dec.com!src.dec.com!stolfi
From: stolfi (Jorge Stolfi)
Newsgroups: comp.lang.modula3
Subject: Re: Two Oberon questions
Message-ID: <9104190752.AA03714@jumbo.pa.dec.com>
Date: 19 Apr 91 07:52:38 GMT
Lines: 54
In-Reply-To: Message of 17 Apr 91 07:23:14 GMT
    from brandis@inf.ethz.ch (Marc Brandis)
    <28054@neptune.inf.ethz.ch>
To: m3
X-Folder-Carbon: lang-des


    [sakkinen] Can function procedures in Oberon return structured values?
    
    [brandis] No. There are good reasons not to allow this.  It is
    rather complicated to implement and it is hard to find good examples
    where you need it.
    
I suppose this is true, provided one looks for such examples only 
in programs written in C, Pascal, Modula-2, or Oberon... 

Seriously, there are many applications that *scream* for structured
return parameters: complex numbers, intervals, rectangles, points and
lines, tagged pointers, array descriptors, etc, etc.

Here at SRC we program in an extension of Modula-2 that supports
structured results; they are used extensively in our system software,
and I at least find them indispensable.
    
    [brandis] If you want to return a structured value, you would have
    to first assemble it into a local variable, which would then be
    copied to the final destination.  In an efficient implementation,
    this would be an implicit VAR parameter.  The common idea in Wirth's
    languages is not to hide what is going on, so in this respect it
    is better to declare the VAR parameter explicitly and to assemble
    the result directly into it.

Using explicit VAR parameters to return results makes programs much
more prolix and unreadable than necessary.  The programmer not only
has to declare (and invent names for) the temporary variables, but
is also forced to use an assembly-like, bottom-up coding style.  Compare

    VAR t1, t2, t3: Complex.T;
      
      Add(a, b, t1);
      Sub(c, d, t2) 
      Mul(t1, t2, t3);
      Sub(t3, u, x) 

with 

    x := Sub(Mul(Add(a, b), Add(c, d)), u)

As for "not to hide what is going on,", please note that high-level
languages were invented specifically to hide the boring details of
programs that are best handled by the computer.  Considering the
relative costs of computer cycles vs. programming manpower, one could
almost say that any coding technique that can be automated
*should* be automated.

In particular, the implicit VAR parameter method labeled by the poster
as "complicated to implement" seems actually quite trivial to me, and
certainly worth the benefit.  Am I missing something?

--jorge