icsu8209@caesar.cs.montana.edu (Glassy) (03/13/90)
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 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? More than one instructor of mine has lambasted Pascal for allowing code like type apple = integer; orange = integer; var a : apple; o : orange; begin ... a := o; ... end. ---------------------------------- Is there some (obvious?) system programming application that is facilitated by structural (vs. name) equivalence? If this issue/question has already been beat to death, my apologies. Thanks, Lou Glassy icsu8209@caesar.cs.montana.edu
drc@cs.brown.edu (David R. Chase) (03/13/90)
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
preston@titan.rice.edu (Preston Briggs) (03/14/90)
In article <3508@caesar.cs.montana.edu> 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. Besides Chase's comments in another article, there's a paper expanding on some of the rationale The Modula-3 type system Cardelli, Donahue, Jordan, Kalsow, Nelson POPL 16, 1989 -- Preston Briggs looking for the great leap forward preston@titan.rice.edu