Re: A (Low-Level) Opaque Object Proposal for R5RS

["R. Kent Dybvig" <dyb@cs.indiana.edu>]

> >--------------------------------------------------------------------------
> > (1) with the passkey
> > mechanism, it will be very difficult to determine all points where
> > access to an object may occur,
> >--------------------------------------------------------------------------

> How is this any more or less difficult than determining all points where a
> slot may be accessed using your record proposal?  Let me be very concrete
> in case there's something subtle I'm overlooking.

First, you have not specified (as far as I've seen) how passkeys are
matched.  In fact, you explicitly left this open in your proposal.
Assuming a string passkey, as in your example, if matching is by
string=?, say, then all bets are off.  Can we agree on this point?  If
so, let's assume that matching is by eqv? and go on, although passkeys
lose some of their utility under this assumption.

Second, what we how have is a two-level analysis problem, which is at
least more expensive and conceptually more complicated than with an
opaque define-record.  After recognizing the pattern produced by your
portable macro, we first must establish that the passkey does not
escape, at which point we can transform the pattern into an opaque
version of define-record.  We can then flow analyze the program as
before.  While this can be done, I'm not enthusiastic about doing it or
the cost associated with doing it, and I'll bet that enough other
implementations won't do it that programmers will learn that the
portable define-record is not efficient enough for their purposes.

> (Of course, one could also build a non-opaque, record-like efficient
> access-by-slot-name mechanism just like your DEFINE-RECORD mechanism,
> (called something like DEFINE-TRANSLUCENT-RECORD) that is just like the
> above opaque macro-based DEFINE-RECORD, only without an underlying opacity
> being involved.  My agenda being that if/when we get around to a module
> proposal or the next neat thing, we won't deadlock on any opacity concerns
> since those could be ironed out later after a non-opaque interface and
> semantics is agreed upon.  In theory, any opaque version could be
> implemented portably by augmenting a non-opaque implementation with the
> right hidden VEIL/UNVEIL stuff.  This at least is my own personal pipe
> dream. ``Some may say I'm a dreamer... but I'm not the only one.'')

I wish it could be this simple, but as an implementor, I will not be
happy with a standardized variant of records (or, likely, modules)
being so open as to prevent fruitful program analysis.  I want my users
to employ the more opaque variants that are more likely to result in
faster and more easily maintained programs.  This means that I will
remain inclined to standardize opaque variants, and arguments of the
form "but you can always define opaque X in terms of Y and transparent
X" will not satisfy me.  On the other hand, I'm happy to provide
portable access to what's left after optimization as long as I'm not
required to retain anything that isn't otherwise needed.

> Huh?  You've totally lost me here.  The weak pointer question that Aubrey
> posted, and Bill's reply to it, were a complete operational side-track
> (read: red herring).  Although an interesting detail that an implementation
> might use to reclaim storage in the general case, weak pointers are no more
> necessary to an `efficient' opaque object mechanism than they are to an
> `efficient' record mechanism.

Bill described how lambda + weak pointers = opaque objects, so if we
were to standardize on weak pointers, we could have a portable opaque
object implementation (with which we could have a portable opaque
record implementation).

> (I did casually browse your web page in search of some hint as to the
> program analysis you have in mind, but I didn't see any titles in your
> on-line publications that suggested such an analysis was discussed.
> ...

Click on Mike Ashley's name under "Ph.D. Students" on my home page, and
go from there to his 1996 POPL paper.  (You can go directly to Mike's
page at http://www.eecs.ukans.edu/~jashley.)  This should give you a
hint about where we're headed, although no explicit mention of records
is made.  His dissertation will be out soon with more.

Kent