Type compatibility rules summary.

Topics related to the use of Oberon language features
Post Reply
cfbsoftware
Site Admin
Posts: 492
Joined: Fri Dec 31, 2010 12:30 pm
Contact:

Type compatibility rules summary.

Post by cfbsoftware » Fri Sep 11, 2020 4:06 am

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

kevinhely
Posts: 29
Joined: Wed May 18, 2011 3:35 am

Re: Type compatibility rules summary.

Post by kevinhely » Fri Sep 11, 2020 11:32 am

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...

augustk
Posts: 54
Joined: Mon Sep 05, 2011 5:21 pm
Location: Sweden

Re: Type compatibility rules summary.

Post by augustk » Sat Oct 31, 2020 9:06 pm

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".

Post Reply