[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Separating opacity from generative record types

> Gerald Jay Sussman writes:
> I would rather that there be limited methods of examining
> and modifying procedures.  Such features are essential when using Lisp
> expressions as a medium for encoding procedural information as a kind
> of data that might be studied or manipulated by a program or a user.
> ...
>   MIT Scheme provides a means of determining details of the formal
>   parameters of a procedure, and more generally a means of obtaining 
>   the sources (when available in a separate file provided by the 
>   compiler).
> ...
> I know that this sounds reactionary, but I persist in viewing
> computational processes as living organisms, which often contain
> valuable information.  There are times to kill them and to reconstruct
> them genetically (from a textual program) and there is time to do
> surgery or other in vivo experiments.
> ... The problem is
> that this vision appears to be in direct conflict with the real need
> to obtain safety and reliability by erecting firewalls that dominates
> the software engineering scene.  Probably, the kind of experimental
> programming that I enjoy and depend upon is just incompatible with a 
> language structure that can be used for software engineering, sigh.

Gerry has struck a cord with this characterization of his position.

I don't think this conflict cannot be resolved.  A decade ago (and perhaps
earlier) Abstract Data Type (ADT) designers were toying with an idea for
providing selective shades of opacity.

In Pebble [Burstall & Lampson 84], for example, an ADT was packaged as a
DOWN operator (to go from abstract type to concrete implementation type),
an UP operator (to go from concrete impl. type to ADT), and an

I find the parallels intriguing.  Gerry (and I) consider a procedure to be
an encoding of data that should be inspectable and alterable, just as the
source code on the file system should be readable and alterable.  And just
as a distributed file system can be protected (e.g., by FTP or NFS/AFS
access control), so too can the source code for a procedure.

And just as one can require a site license w/ non-disclosure for code
sources, one could apply the same policy to release of the object->source
mapping files that Gerry alludes to above in MIT Scheme (the .bci files),
or whatever physical distribution mechanism is used to release ADT
implementation details in machine readable format.

Alternatively, one could play all sorts of games with encrypted access and
other means of authentication and privacy control, including
``implementation escrow'', etc. to regulate abstraction violations.

I could even imagine an ``abstraction observance license agreement'' shrink
wrapped on code distributions.

In the extreme case, those who demand absolute and total opacity for their
code (to please their compilers) could simply chose not to participate in
sharing their implementation details with anyone (who is not a compiler).


The distributed object community and the Internet financial transaction
community seem ripe with ideas for how to address just these sorts of
distribution access control issues.  Perhaps a careful survey of the
literature might reveal a nice compromise for those who insist on opacity
in a language and those who despise it.  This could, for example, make a
nice area exam assignment for some graduate student interested in language
design and distributed/network security.  (And given the current Java hype,
there $urely must be plenty of students intere$ted in that topic!)

In the case of password based capability control, those who loathe opacity
could, for instance, always make their ADT password be something well
advertised, like ``Opacitus vaccuuo rox'' (dog latin for ``Opacity sux
rocks'') or, in Gerry's case, just ``Moby foo''.

One could also build a macro layer atop the underlying opaque system to
suppress the whole issue of passwords, or whatever, when the access
mechanism is public and fixed.  Gerry could then use his macros and forget
the whole issue.

In short, those who do not choose to enforce their abstraction barriers
should not be required to do so.


My point is that we can (and should) separate the opacity issues from the
other language mechanisms people are proposing.

We should, for instance, be able to proceed with a record proposal that
does not include opacity. Then, as a separate issue, we could explore
proposals for opaque packaging to seal an interface's implementation in
some ADT or some other buzz word.

After all, the raison d'etre for a record system is to provide convenient
and efficient name-based slot access, _not_ to provide ADT's.  The whole
issue of opacity in the case of record type descriptors is somewhat of a
red herring: opacity is an issue that should (and should) stand on its own.

Similar issues arise when considering module systems.  In that case too I
believe the truly Scheme-ly thing would be to separate the opacity issues
into a separate and orthogonal mechanism, distinct from the name scoping
issues that modules are truly aimed at addressing.

The exception/interrupt/restart proposals seem to be brushing up against
this opacity non sequitur as well.

For any data object, be it a record/record-type, module/interface,
condition/condition-type, procedures/environments, or even a ``unique
user-defined type'' mechanism, the issue of opacity should be addressed by
a separate packaging mechanism, one that masks the underlying
representation issue in a way that can be run-time enforced. Or not.

In particular, enforcing the abstraction barriers could involve testing a
bit in the object representation for opacity (as with implementations that
efficiently encode mutable/immutable) or some other, more expensive
mechanism.  Different Scheme implementations will naturally chose different

Any given opacity implementation could pervade the objects in the system
(marking them with bits) or it could be quite separate (defining a new
aggregate data type that satisfies no existing type predicts, like PAIR?
or VECTOR?).  Different Scheme implementors will naturally choose different
strategies, as they should.  This is good.


It is not the place for orthogonal proposals (like records, modules,
exceptions, etc.) to address this issue of opacity as some sort of rider
clause or as a last-minute amendment. This is not to say that opacity isn't
important.  It is just a different issue.  It should ride its own bill.

I have my own straw-man proposal that I will send in a separate post.


So, is it possible for those who demand opacity to spawn a separate
``opacity packaging'' subcommittee or working group to explore an
orthogonal opacity proposal while not opposing the adoption of a record
proposal that does not mix in issues of opacity?  Could you also then not
oppose non-opaque module system proposals?  Or exception systems?  Or
translucent procedures?

Seriously, each of these could be wrapped/packaged in an opacity guardian
to independently address the impenetrable abstraction barriers that some
seem to demand.  Those who then wish to enforce opacity to allow clever
compiler tricks could devise natural macros to enshroud the objects of
interest in an opacity guardian as a matter of course.

I'm curious to know just how intransigent the opaque brigade is on this
issue.  Would spawning a separate ``Guardians of opacity'' working group to
explore this orthogonal issue be enough to disarm your categorical
opposition to any proposal that does not itself mix opacity issues into the
_real_ mechanism that people are trying to standardize?

I, for one, am of two minds on the issue of opacity.  There are situations
where I want it sometimes and there are situation where I detest it
sometimes too.  To me, this is the first sign that opacity is orthogonal to
the other concerns at issue.

The Burstall and Lampson paper does a wonderful job of clearly separating
these issues.  I highly recommend it.



[Burstall & Lampson 84]

  Burstall, R., and Lampson, B.
  ``A kernel language for modules and abstract data types.''
  Digital Equipment Corp. Systems Research Center.
  Sept. 1, 1984; pp 51
  Keywords:  pebble, language constructs