sakkinen@jyu.fi (Markku Sakkinen) (04/12/91)
(I suppose these are currently the two most appropriate groups for
discussions about Oberon.)
First question:
How is the type equivalence of two objects really defined in Oberon?
Modula-2 has "name equivalence", but Modula-3 has gone over to
structural equivalence (in my opinion: unfortunately).
Wirth's original language definition in Software - Practice and Experience
(July 1988) sidesteps this question rather completely.
However, it is not even allowed to use the name of a previously
defined procedure type to declare the type of a procedure being defined.
This is a kind of structural equivalence. On the other hand,
type equivalence is not mentioned among the differences in the
companion paper (same issue of S-P&E) "From Modula to Oberon".
Second question:
Can function procedures in Oberon return structured values?
In Modula-2 they cannot, but in Modula-3 this defect has been corrected.
Again, the language definition carefully avoids saying anything
(which would imply "yes"), but neither is this mentioned as a difference
from Modula-2 (which would imply "no").
Common addition to both questions:
Has the principle perhaps even been changed over the years?
Do different implementations of Oberon differ?
Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
SAKKINEN@FINJYU.bitnet (alternative network address)preston@ariel.rice.edu (Preston Briggs) (04/13/91)
sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: >First question: >How is the type equivalence of two objects really defined in Oberon? >Modula-2 has "name equivalence", but Modula-3 has gone over to >structural equivalence (in my opinion: unfortunately). >Wirth's original language definition in Software - Practice and Experience >(July 1988) sidesteps this question rather completely. In a later paper, perhaps about the Oberon system, Wirth let slip that Oberon (the language) uses name equivalence. Of course, you have to make these exceptions for procedure passed as parameters, and pretty soon you end up wishing he had just said structural equivalence and let it go at that. >Can function procedures in Oberon return structured values? Nope. This one is in the report, somewhere. Of course, I may be out of date. Preston Briggs
brandis@inf.ethz.ch (Marc Brandis) (04/17/91)
In article <1991Apr12.104304.4194@jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: >How is the type equivalence of two objects really defined in Oberon? >Modula-2 has "name equivalence", but Modula-3 has gone over to >structural equivalence (in my opinion: unfortunately). Oberon uses name equivalence as does Modula-2. There are two special cases in which structural equivalence is used: Open arrays and procedure variables. >Can function procedures in Oberon return structured values? 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. 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. Note that you cannot use the result of such a function in an expression. All what you could do with it would be to assign it to another variable or to pass it to a procedure as a parameter. If you look at the intended programming style in Oberon, you will see that structure assignments and passing of structures as value-parameters occurs rarely. >Do different implementations of Oberon differ? The implementations of Oberon implemented at ETH do not. I cannot comment on other implementations, but I guess that the answer is also no. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
sakkinen@jyu.fi (Markku Sakkinen) (04/17/91)
In article <1991Apr12.104304.4194@jyu.fi> I asked: >First question: >How is the type equivalence of two objects really defined in Oberon? > ... >Wirth's original language definition in Software - Practice and Experience >(July 1988) sidesteps this question rather completely. > ... It seems that this crucial issue really remains undefined! I could not find any mention of it even in the newest revision (Oct. 1990) of the language report, as available by anonymous FTP from ETH Zurich. >Second question: >Can function procedures in Oberon return structured values? > ... Oh dear, already the original language report clearly said 'no' in subsection 10.1; how could I have failed to note it? Therefore, no improvement over Pascal and Modula-2, unfortunately. However, since SET is one basic type in Oberon (instead of constructed set types as in Pascal and Modula-2), it is allowed as a return type. >Common addition to both questions: >Has the principle perhaps even been changed over the years? >Do different implementations of Oberon differ? According to the answers I received, implementations apply "name equivalence" to types. Thanks once again to everybody who sent answers or comments! Markku Sakkinen Department of Computer Science and Information Systems University of Jyvaskyla (a's with umlauts) PL 35 SF-40351 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative network address)
vsanchez@casbah.acns.nwu.edu (Victor Sanchez) (04/19/91)
>In article <1991Apr12.104304.4194@jyu.fi> sakkinen@jytko.jyu.fi (Markku Sakkinen) writes: > >>Can function procedures in Oberon return structured values? > No. But it is not needed (I think). Please somebody correct me if I am wrong, but if you have automatic garbage collection you can use the pointers to structures in a more flexible way. e.g. suppose we are writing a set of function that perform operations on matrices. We define a structure called Matrix. We would like the functions to return a matrix structure so we can chain the operations: a = MultMat(a,AddMat(b,c)); instead of AddMat(b,c,temp1); MultMat(a,temp1,a); This cannot be done if the functions deal with pointers to Matrices, because, for example the routine MultMat cannot DISPOSE(a) and then assign it the new pointer to the structure. If garbage collection exists then we can happily change the place in memory pointer "a" is pointing to, the garbage collector will realize that the old memory pointed by "a" is not used anymore and make it available. So you can now use pointers to structures complety to replace return structures, perhaps one pays a price for that, but returning structures is not very efficient anyways. Is this correct? Or am I missunderstanding the way garbage collection works? Victor Sanchez
stolfi (Jorge Stolfi) (04/19/91)
[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?
--jorgestolfi (Jorge Stolfi) (04/19/91)
[sakkinen] Can function procedures in Oberon return structured values?
[vsanchez] ... if you have automatic garbage collection you can
use the pointers to structures ... perhaps one pays a price for
that, but returning structures is not very efficient anyway.
Garbage collection and pointers can replace structured return values
in some uses, but not all.
It should cost only two or three instructions to return a two-word
record as a procedure result. If you account for the cost of running
the garbage collector, allocating that same record from the heap may
well cost thousands of instructions---two or three orders of magnitude
more.
So, the pointer/heap solution is acceptable only in some cases: for
low-intensity uses, for large structures, for values that will get
copied many times, etc.. For many other uses (complex numbers, points,
dates, etc.) structured return values will be a lot cheaper.
Moreover, in languages like Modula-2 and Pascal, the use
of heap records requires extra code: NEW calls, "^" operators,
temporary variables. Structured return values are more natural
and easier to use.
Finally, allowing structured return values does not mean making the
language more complex; on the contrary, it means removing a rather
arbitrary rule...
Jorge Stolfi
DEC Systems Research Center, Palo Alto
stolfi@src.dec.com
----------------------------------------------------------------------
DISCLAIMER: Don't blame me, I'm only a user.
hudson@yough.cs.umass.edu (Rick Hudson) (04/19/91)
stolfi@src.dec.COM writes: > > It should cost only two or three instructions to return a two-word > record as a procedure result. If you account for the cost of running > the garbage collector, allocating that same record from the heap may > well cost thousands of instructions---two or three orders of magnitude > more. > Around here we sit around and count the number of instructions/record it takes to do allocation and garbage collection on our fingers. This myth that GC takes thousands of instruction for each allocation just isn't true. I agree that structured returns are certainly useful, but the readability and expressability arguments are the important ones. - Rick