[M3devel] Branding?

Rodney M. Bates rodney_bates at lcwb.coop
Mon Nov 23 17:27:28 CET 2009


jay.krell at cornell.edu wrote:

This may be an incomplete answer but...
> What are the low level ramifications of "branding"? "object model", 
> "ABI", "C equivalent", etc.?
The ramifications are all at the static , type-checking level, and will only
affect code written in Modula-3. 
>
> Specifically:
> 1 my recent change to "Activation" is idiomatic? And correct? "frame" 
> field is still at offset 0? (I was too lazy to read the code. Nonzero 
> is ok but might be less efficient depending on instruction set.)
What source file is the change to "Activation" in?
>
> 2 How to make pthread_mutex_t and pthread_cond_t distinct types (and 
> still preferably opaque, but "made up" if necesary) to avoid getting 
> the parameters to wait_cond reversed? Untraced branded ref to
> empty records with different brands? Note OF COURSE the instatiation 
> is never in Modula-3.

If two types are BRANDED with different brands, they will always be distinct
types, even if they point to the same type.   Also, if at least one of 
the brands
is omitted, then the language will ensure they are different.

And of course, there will never be any cross-language type checking,
no matter what the languages are. 
>
> You know, what is equiv of important  C idiom:
>
> Typedef struct xfoo *foo_t;
> Typedef struct xbar *bar_t;
>
> Where xfoo and xbar may or may not ever be defined ("revealed")?
>
>  - Jay (phone)
>
Modula-3 type equality is almost always "structural", i.e., two different
occurrences of the same type definition denote the same type.  Putting
a brand on a type alters this to the oft-misnamed "name" equivalence.
(But only reference types can be branded).

All the books and the C standard say C type equivalence is structural
between separate compilations and "nominal" within a compilation.  This
is in one respect, highly misleading, and an outright lie in another.

The lie is that, even within a single compilation, the type equality
rules are structural for those type constructors that use the declarator
syntax.  (One could hardly live with nominal rules here, with the
pervasive need to duplicate pointer declarators everywhere.)
Equivalence is nominal for the type constructors that are
user-written type specifiers. 

The misleading part is that, between compilations, the rules are indeed
structural, but the meaning of type "equality" is quite different.  
Within a
compilation, type equality is checked by the compiler, at least to the 
extent
of the weak type rules of the language.  Across-compilations, type
equality only means things will work as expected, while lack of
(structural) equality is  "undefined", meaning you will get no
help from the compiler if you make a mistake.





More information about the M3devel mailing list