Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site noscvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ittatc!dcdwest!sdcsvax!noscvax!broman
From: broman@noscvax.UUCP (Vincent P. Broman)
Newsgroups: net.lang.mod2
Subject: structured function values
Message-ID: <53@noscvax.UUCP>
Date: Sat, 12-Oct-85 00:39:05 EDT
Article-I.D.: noscvax.53
Posted: Sat Oct 12 00:39:05 1985
Date-Received: Mon, 14-Oct-85 06:11:22 EDT
Distribution: net
Organization: Naval Ocean Systems Center, San Diego
Lines: 45

<>

     Modula-2's restriction of function procedure results to be of 
unstructured types seems to have no solid justification.  Many implementations 
of C and some of Pascal allow functions to return structures, as also all 
valid Ada implementations, of course. A consistent application of the 
philosophy behind Modula-2 would allow functions to return values of any type.  

     Acceptable implementations of complex arithmetic, vector/matrix 
arithmetic, string manipulation functions, etc, require functions which can 
return structures.  If every invocation of a routine requires a separate source 
line, we miss the grouping and abstracting power of expressions, which is one 
advantage FORTRAN has over assembly language.  A computation may appropriately 
be invoked inside an expression if it has no side-effects, produces one output 
value, and is conceptually simple.  Then we desire a function procedure over a 
proper procedure with a VAR parameter, whatever type the value to be returned 
may have.  That is the most appropriate notation to abstract that algorithm.  

     Function calls are usually implemented with values returned in the 
machine's fast registers, providing they fit in that much space.  This 
limitation does not preclude the compiler's implementing function calls which 
return ARRAYS and RECORDS internally as procedure calls.  The return value is 
then placed in temporary store via an extra VAR parameter.  This slight 
complication hardly justifies introducing a hardware dependency into the 
language.  

     Allowing structured function values will not introduce strange notations 
like func(arg).field or func(arg)[sub] because the components of a structure 
are accessed with the syntax: "designator=qualident{selector}", and a function 
call is not a qualident.  However, Modula allows at present, as far as I can 
see, such curiosities as "ffunc(arg)(arg)" if ffunc is a function returning 
a function, or funcarray[sub](arg) for arrays of functions. Not allowed at 
present is pointerfunc(arg)^ . None of these notations seems objectionable to 
me, though I would welcome explanation of dangers connected with such 
liberties.

     I have never written a compiler myself, so I invite correction if my 
suggestion would create unacceptable difficulties.  My respect for Wirth's 
achievement in creating Modula-2 is great, and I applaud loudly his spartan 
philosophy in language design.

Vincent Broman   (619) 225-2365      MILNET: broman@nosc
Analysis Branch, code 632            UUCP: {ihnp4,decvax,akgua,dcdwest,
Naval Ocean Systems Center               allegra,ucbvax}!sdcsvax!noscvax!broman
San Diego, CA  92152                 ICBM: 32deg 42min N / 117deg 14min W