broman@noscvax.UUCP (Vincent P. Broman) (10/12/85)
<>
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 Wdick@ucsfcca.UUCP (Dick Karpinski) (10/15/85)
In article <53@noscvax.UUCP> broman@noscvax.UUCP (Vincent P. Broman) writes: > Modula-2's restriction of function procedure results to be of >unstructured types seems to have no solid justification. Many implementations Modula-2 does not restrict function results. Some implementations do but Wirth allowed that those were indeed implementation restrictions. The British Standards Institution is midway into producing a candidate for ISO standardization, and they allow functions to return anything. I don't know why you should not be able to dereference or subscript function results, but neither the Report nor the developing standard permit that. Incidentally, I am acting as the US distributer for BSI documents on Modula-2. Write for details. Mostly, documents are available for about 10 cents per page. i would be anxious to discover any way to do low volume demand publishing from paper masters for less. Also want to find access to OCR in order to make machine readable without rekeying 50 page documents. Dick -- Dick Karpinski Manager of Unix Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 666-4529 (12-7) BITNET: dick@ucsfcca Compuserve: 70215,1277 Telemail: RKarpinski USPS: U-76 UCSF, San Francisco, CA 94143
rcd@nbires.UUCP (Dick Dunn) (10/15/85)
>... Modula-2's restriction of function procedure results to be of > unstructured types seems to have no solid justification... Agree. >... Function calls are usually implemented with values returned in the > machine's fast registers, providing they fit in that much space... The "...providing..." here is an important point: As long as it's necessary to make provision, in some architectures, for returning results somewhere other than a register, 1. There's no justification for excluding those processors from the language, nor introducing a processor dependency on the result type of a function, hence 2. "Returnable in a register" is not a reasonable argument for the restriction on result type. >... 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)^... There's no particular reason to disallow the new constructs once a function can return a value of a type which makes them reasonable. The restriction against pointerfunc(...)^ also existed in Pascal. I have never understood why it should exist; in fact, we removed this restriction in a Pascal-based language I worked on some years ago. (That same language also allowed functions to return structured results, with no particular problems.) The overall effect on the language, if anything, is to make it more uniform. > I have never written a compiler myself, so I invite correction if my > suggestion would create unacceptable difficulties... Again, talking about the Pascal-based language that I worked on, my notes say that it added about 150 lines to the compiler (which was a variant of the ETH compiler). That's small change. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Simpler is better.