Re: New types; also opacity without passkeys [portable R4RS impl]

[William D Clinger <will@ccs.neu.edu>]

Bill Rozas wrote:
> I would like to understand this part.  If you allow redefinition of
> existing procedures so that code distinct from this package uses the
> new definition, you should be able to implement this, albeit
> painfully.

Nice idea!  I forgot about the possibility of adding opacity to
Scheme by eliminating some of the standard procedures through
redefinition.

Michael Blair wrote:
> I believe you must have meant:
> 
>  6.   ((GET-NEW-PREDICATE <type2>) (U <object>)) = #F
>                                    ^^         ^
>                                    ++         +

That's probably what I meant.  I don't remember.

> Yes, it can.  Following is a portable R4RS implementation that I have
> tested in both MIT Scheme and Scheme 48.  It relies _only_ on the
> opacity of LAMBDA closures.

Blair's implementation doesn't satisfy axiom 5, because
(GET-NEW-PREDICATE <type>) returns true on some objects that
weren't actually created by (GET-NEW-CONSTRUCTOR <type>).
Below is a transcript from MacScheme; presumably MIT Scheme
and Scheme 48 give the same result.

>>> (begin (define <type> (MAKE-NEW-TYPE))
           (define U  (GET-NEW-CONSTRUCTOR <type>))
           (define P? (GET-NEW-PREDICATE <type>)))
p?
>>> (let ((x (U 37)))
      (P? (cons (car x) (cdr x))))
#t

Aubrey Jaffer wrote:
> I think Will meant that this condition could not be satisfied
> simultaneously with new-types being distinct from R4RS-defined types.

No, I meant that it was not possible to solve the above problem
in R4RS Scheme.  I was wrong, as Rozas pointed out.

I still think it is impossible to solve the above problem in
R4RS Scheme without assuming that the MAKE-NEW-TYPE module is
loaded first, before any other modules have had a chance to
capture any of the standard procedures.  That assumption is
necessary for DYNAMIC-WIND also, however, so I think it's a
fair assumption to make.

Will