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

[Michael R. Blair <ziggy@martigny.ai.mit.edu>]

Drat!  I sent a corrupted version of this post to the RnRS authors list.

The (short) correction is in the discussion of flattening the MAKE-RECORDFOO
constructor.  It read:
>--------------------------------------------------------------------------
> In-lining the call to <hidden-underlying-opaque-type> results in:
> 
>       (SET! make-recordfoo
>             (LAMBDA (fieldfoo)               ; in-lined OPAQUE-VEIL call
>               (LET ((attempt
>                       (%OPAQUE-OBJECT-NEW <hidden-underlying-opaque-type>
>                                           (VECTOR "Record Foo"  ; tagged vect
>                                                   fieldfoo))))
>                 (IF (AND (EQ? (AND (%OPAQUE-OBJECT?     attempt))
>                                    (%OPAQUE-OBJECT-TYPE attempt))
>                               <hidden-underlying-opaque-type>)
>                          ;;; in-lined %PASSKEY-MATCH?
>                          (OR (EQ? <hidden-passkey> <hidden-passkey> )
>                              (STRING=? <hidden-passkey> <hidden-passkey>)))
>                     attempt
>                     (ERROR "OPAQUE-VEIL:  Non-matching <passkey>"
>                            <hidden-underlying-opaque-type>
>                            <hidden-passkey>)))))
> 
> To continue then, at this point, USE/DEF analysis of `attempt' reveals that
> it is not side-effected so program flow analysis can conclude that the test
> in the IF form must evaluate to TRUE.
>--------------------------------------------------------------------------

This part that followed was broken (I didn't save my Emacs buffer. Foo!)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x  The (PAIR? attempt) test result can
x  be deduced from mere type analysis but the test for the value specific (EQ?
x  (CAR attempt) *opaque-object-tag*) where *opaque-object-tag* is a hidden
x  implementation constant used to tag opaque objects requires either a very
x  aggressive
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
It should have read:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+  Since %OPAQUE-OBJECT-NEW, %OPAQUE-OBJECT? and %OPAQUE-OBJECT-TYPE are
+  kernel-level abstractions known to the compiler (e.g., they could be
+  implemented as assembly-level primitives so the user cannot infiltrate them
+  as Scheme source), program flow analysis can reduce the first arm of the
+  outermost AND to TRUE.  This is because %OPAQUE-OBJECT-NEW will result in
+  an opaque `attempt' object that satisfies %OPAQUE-OBJECT? and, further, the
+  resulting opaque object will have opaque object type that is EQ? to
+  <hidden-underlying-opaque-type> because the call to %OPAQUE-OBJECT-NEW that
+  created `attempt' is lexically apparent, constant, and has as its
+  opaque-type argument the known variable <hidden-underlying-opaque-type>.
+  
+  This requires a program flow analysis akin to being able to determine that
+  (%CAR (%CONS x y)) = x, for kernel-level primitive %CAR and %CONS.  The use
+  of `%' in the names is a convention for indicating that it is the underlying
+  machine primitives we are considering and not the binding of some variable
+  `CAR' that is assumed to be bound to the primitive CAR.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The xxx'd out gibberish above about PAIR? and CAR was discussing what
would be necessary of the kernel-level %OPAQUE-<mumble> were in-lined as
Scheme source, as a partial evaluator might do it.  This was a bad idea.
I backed out of it by appealing to the fact that the kernel-level
%OPAQUE-<mumble> primitives could be known to the compiler, just as a
compiler can know that (%CAR (%CONS x y)) = x, for kernel-level primitive
%CAR and %CONS.  This, then, does not appeal to partial evaluation (or any
other form of aggressive constant folding).

Unfortunately, I did not save these corrections in the Emacs buffer that
held my message before launching it off to the list.  Mea culpa.  I'm
sorry.  I hope this has not generated too much confusion.

What followed for the rest of the message was what I intended...
>--------------------------------------------------------------------------
> Therefore, the result is this:
> 
>       (SET! make-recordfoo
>             (LAMBDA (fieldfoo)               ; in-lined OPAQUE-VEIL call
>               (LET ((attempt
>                       (%OPAQUE-OBJECT-NEW <hidden-underlying-opaque-type>
>                                           (VECTOR "Record Foo" ; tagged vect
>                                                   fieldfoo))))
>                 attempt)))
> 
> which becomes:
> 
>       (SET! make-recordfoo
>             (LAMBDA (fieldfoo)               ; in-lined OPAQUE-VEIL call
>               (%OPAQUE-OBJECT-NEW <hidden-underlying-opaque-type>
>                                   (VECTOR "Record Foo"   ; tagged vect
>                                           fieldfoo))))
>--------------------------------------------------------------------------

Etc.

Sigh. At times like these I wish there were an automated way to cancel
a post send via email and replace it with a corrected version.

<< C'est le guerre. >>  [trans. for Sussman:  ``Moby foo!'']