🚀 go-pugleaf

icsu8209@caesar.cs.montana.edu (Glassy) writes:
>Page 2, Sect. 2, Par. 1 Line 1 of "Modula-3 Report (revised)" by
>Cardelli, Donahue et al indicates Modula-3 uses structural type
>equivalence, instead of name type equivalence used in Modula-2.

I'll comment in my capacity as a member of the "peanut gallery"; this
isn't the definitive answer, but it should help.  The subject was much
discussed. 

>I thought (perhaps mistakenly) that name equivalence was both
>easier to implement, -and- more secure than structural equivalence.
>If this is true, why does M-3 get structural equivalence?

No mistake here; think about what it means to get structural
equivalence working, and then think about your linker.  Nasty mess.
You'll note that there is also "branding", and restrictions on what
types can be made opaque.  Branding gets you name type equivalence,
but only for REF (garbage-collected pointer/object) types.  I believe
(though I'm not certain) that the restrictions on branding and opaque
types makes life somewhat simpler for the linker.

>Is there some (obvious?) system programming application that is
>facilitated by structural (vs. name) equivalence?

Yes indeed.  Think about preserving (bulk) data onto disk.  If you use
name equivalence, all sorts of messy problems arise (trust me, they
arise) with different versions of software, trivial edits to code,
etc.  Structural equivalence makes this pretty easy -- if it conforms,
then you can read it.  Branding provides a way to get an exact global
name for a type, no matter what happens to the program (though there
is a default brand if you don't specify one that acts pretty much like
by-name equivalence).  Anyhow, the pickling (that's what they call it)
is pretty spiffy -- both DEC-SRC and ORC (RIP) implemented different
pickling packages.  At least for the Olivetti code, a little compiler
and linker assist went a long way.  It worked well.

One reason to dislike structural equivalence is that it can lead to
some weird surprises if the programmer ever uses TYPECASE.  Think
about implementing an AST, for instance, and the possibility of
accidentally defining two node types with identical structure.  The
argument was made, at least one, that TYPECASE was not object-oriented
and thus this didn't really matter (I think that's how the non
sequitur went).

>If this issue/question has already been beat to death, my apologies.

Oh, it's been beaten to death, but probably not in public.

David