Page 1 of 1

Type compatibility rules summary.

Posted: Fri Sep 11, 2020 4:06 am
by cfbsoftware
An interesting question about the type compatibility rules was recently posted here but was deleted by the user before I had a chance to reply. As it happened it actually highlighted a problem which has since been fixed in v7.2 of Astrobe.

A good summary of Oberon's type compatibility rules which helps to answer these sorts of problems has been produced by Karl Landström (aka August Karlstrom), the author of OBNC, the Oberon to C translator. It is available here:

https://www.miasap.se/obnc/type-compatibility.html

Re: Type compatibility rules summary.

Posted: Fri Sep 11, 2020 11:32 am
by kevinhely
Hi,

I think you're referring to a question I posted but then deleted because I discovered it had already been answered earlier on this forum.

The summary you link to mixes up types and type identifiers, and defines "same type" for two variables but then uses the term "same type" in a context that does not involve variables. Nevertheless, I think it's a useful document (and shows that it is possible to be clear about such matters without taking pages and pages, as has been claimed before). It should be in the official language definition, whose brevity has been achieved at the cost of some ambiguity...

Re: Type compatibility rules summary.

Posted: Sat Oct 31, 2020 9:06 pm
by augustk
kevinhely wrote:
Fri Sep 11, 2020 11:32 am
The summary you link to mixes up types and type identifiers, and defines "same type" for two variables but then uses the term "same type" in a context that does not involve variables. Nevertheless, I think it's a useful document (and shows that it is possible to be clear about such matters without taking pages and pages, as has been claimed before). It should be in the official language definition, whose brevity has been achieved at the cost of some ambiguity...
If you have any suggestions on how to improve the clarity, please let me know. Now that I reread the paragraph about non-strict name equivalence I agree that using the names T_a, T_b and T_c for type identifiers is maybe not the best choice since these names are used throughout the document to denote types in general (possibly anonymous types). The other definitions where "same type" is mentioned are the same as in appendix A from "The Programming Language Oberon-2".