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