Re: Why would anyone want opacity?

[Guillermo J. Rozas <gjr@martigny.ai.mit.edu>]

|   Date: Tue, 30 Apr 1996 16:13:13 +0000
|   From: William D Clinger <will@ccs.neu.edu>
|
|   I also find that some of my students who use Scheme will use the
|   read/eval/print loop or an inspector to learn the representations
|   even if I provide only compiled code.  Sometimes I have to laugh
|   at the effort some students will expend toward writing poor code.

Interesting, but you probably consider young kids who are interested
in how their radios/CDs/cars/computers work, and learn to probe them
and improve them, quite imaginative and would encourage them.

Why do you treat software differently?  It is _just_ another
engineering product.  No less, and _no more_.

The dangers of unnecessarily breaking abstractions can be explained or
imposed, but they are learned from experience.  Allow them to gain it,
rather than learn to resent a straightjacket, or worse, limit their
imagination.

|   One motivation that Alan didn't mention at all is the desire to
|   generate more efficient code.  If there is any possibility that
|   a value will escape from some compilation unit and be examined
|   by some abstraction-breaking facility, then the compiler must
|   represent the value in some standard format that is understood
|   by the abstraction-breaking facility.  These standard formats may
|   be less efficient than the formats that the compiler could use for
|   values that will never be exposed to the abstraction-breaking
|   facilities, because they must encode the information that is made
|   available by those facilities.

Or the compiler leaves an annotation describing the mapping so that it
can use the more efficient representation, but then convert it into
what the user expects when using the meta-programming facilities.

The various MIT Scheme compilers get rid of variables, choose frame
formats and layouts, etc. with relative impunity.  They just leave
"debugging" information behind that is accessed by the
meta-programming facilities to make it appear to their user that
nothing had happened, or to tell him/her that the naive model is
broken (e.g. mutability of variables).

Yes, this means more work and a more complex model for the user of the
meta-programming facilities, but so what?  Your alternative is not to
provide them at all.

|   Note that this does indeed constrain the executable representation!
|   If Gerry is to be able to edit the procedure C defined by
|
|       (define c
|	 (let ((n (read)))
|	   (lambda () 0)))
|
|   so that its code becomes (LAMBDA () (SET! N (+ N 1)) N), then the
|   compiler won't be able to transform the above definition into the
|   otherwise equivalent and probably more efficient definition
|
|       (define c
|	 (begin (read)
|		(lambda () 0)))
|
|   If this is a local definition, then (under certain circumstances)
|   the compiler ought to be able to transform a call to C into the
|   constant 0, which may enable some further worthwhile optimizations.
|   A compiler that performs these optimizations won't satisfy Gerry.

But a compiler that tells him that the binding is gone, or that the
code for the procedure is your second alternative will satisfy him.

|   It appears to me that, in order to satisfy Gerry, a compiler must
|   treat all variables as if they were (pardon the expression) VOLATILE.
|   This is a considerable price to pay for an abstraction-breaking
|   facility that not even Gerry is likely to use very often.

No, you are assuming that Gerry is not smart enough to deal with
anything but a naive model of compilation.  Let the compiler explain
(at some level) what it has done in a language that Gerry can
understand.  Gerry can pick up from there.
Furthermore, even more importantly than Gerry, let higher-level
meta-programming tools (e.g. debuggers) use the information.