An interesting question about the type compatibility rules was recently posted here but was deleted by the user. As it happened it actually highlighted a problem which was subsequently 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
Type compatibility rules summary.
-
- Site Admin
- Posts: 525
- Joined: Fri Dec 31, 2010 12:30 pm
- Contact:
Re: Type compatibility rules summary.
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...
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.
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".kevinhely wrote: ↑Fri Sep 11, 2020 11:32 amThe 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...