🚀 go-pugleaf

In article <NEITZEL.89Jul5042938@pollux.uucp> neitzel@tubsibr.uucp (Martin Neitzel) writes:
>
>> MSRS002@ECNCDC.BITNET ("THE DOCTOR."), slightly reformatted:
>DOC>
>DOC>	TYPE  OneType = CARDINAL;  AnotherType = CARDINAL;
>DOC>	
>DOC>	Are the types OneType and AnotherType compatible?  PIM3 seems
>DOC>	to say they are both compatible with CARDINAL, but doesn't say
>DOC>	much about compatibility with each other.
>
      It's really annoying that this comes up in Modula 2.  It was 
ambiguous in Pascal, it was ambiguous in Modula 1, and it's still giving
trouble.  At least Wirth is consistent; each new language definition
contains the same old bugs.

      Neitz gives a nice description of the argument for type compatability
by form.  There is also a good argument for compatibility by name.  One
might wish to declare types named, say, "Inches" and "Pounds", or even
"ProcessTableIndex" and "FileTableIndex" and have them be protected from
use with the wrong procedures.  Ideally, you should be able to make a
type opaque when this sort of behavior is desired.  Unfortunately,
opaque types in Modula 2 are very limited; they must be pointers.
This simplifies separate compilation, but makes the concept much less
useful.

      Of course, what we are really doing here is trying to sneak up
on object-oriented programming.  You really want the ability to declare
variables of opaque types, have them initialized properly, have them
be protected from modification outside their own module, and have them
closed out properly when they become deleted through exit from a dynamic
scope.   This describes the basics of an object-oriented programming
system.  In many ways, object-oriented programming is the end of a long
road that began with the introduction of strong typing.  Trying to fix
the typing mess short of fully supporting objects is very painful.
Ada represents a good try.

					John Nagle