🚀 go-pugleaf

In article <1991Jan30.091656.4348@mack.uit.no>, torbjorn@forit.forut.no
 (Torbjorn Sund) writes:
  
> Who says that an opaque type is assignment or storage equivalent to ADDRESS?
> At least one compiler (FTL) did not impose the restriction that an
> opaque type be implemented as a pointer.

Hear, hear!  I use the FTL compiler a lot, and one of the things I like about
it is that it implements opaque types "properly".  Those compilers which
insist that TSIZE(OpaqueType) <= TSIZE(ADDRESS) are, IMAO, next to useless.

Why? (a) opaque types are very important in allowing a "clean" programming
style (i.e. information hiding is important, and the language should allow
it), and (b) more often than not, the "natural" implementation of an
opaque type turns out to be a record, or something else which takes up a
moderate amount of storage.

Most compilers for Modula-2 force you to
implement an opaque type as a pointer to the type which you really wanted,
which means that the implementation code contains lots of pointer
operations which in principle did not need to be there and which render
the implementation code, in some cases, as clear as mud.  (True, I use
pointers a lot and find them useful, just as GOTO was very useful back in
the days where I had to use Fortran - but both pointers and GOTOs are
makeshift solutions which are forced upon us by language limitations, and
should not be needed in a reasonable high-level language.)

There is one little catch in the solution used by the FTL compiler to
allow unrestricted opaque types: when it compiles an implementation module
and discovers what the opaque type really is, it has to go back and modify
the symbol file (i.e. the thing which was created when the definition
module was compiled).  This causes problems in working out inter-module
dependencies (i.e. in working out which object modules are out of date),
and may be one of the reasons why the "make" facility supplied with the
FTL compiler keeps crashing.  Crazy things can also happen when the
definition module and the implementation module are in different
directories.  These are just compiler bugs which will presumably
be fixed in some future version, but they do illustrate the hidden traps
which a compiler-writer faces when trying to do the right thing about
opaque types.

At least one other compiler - sorry, I've forgotten its name - has an
ingenious solution: it implements opaque types as pointers, but does not
require the user to know about this.  That is, it allows anything as an
opaque type, and then inserts extra indirection, which is not visible to
the programmer, as needed for its own convenience.

Peter Moylan                    eepjm@cc.newcastle.edu.au