[R6RS] record types and UIDs

[dyb at cs.indiana.edu]

> I agree with the need for good error messages. I imagine that the above
> situation would be handled the same was as for non-UID record types;
> the error message should be something like
>
>  posn-x: expects args of type <record:posn>; given instance of a
>  different <record:posn>
>
> Is there some reason why this strategy doesn't work with
> UID-prefix-based record types?

With the original proposal, the error occurs when an attempt is made to
create a different record type with the same UID, not later when (or if)
an invalid access is attempted.

This does not merely mean that the error is detected at a different time.
In some cases, the error may be detected in the original model where it
would go undetected in the "UID prefix" model.  For example, code that
dispatches on the type of a record via the record predicate may break
silently with the "UID prefix" system since it never attempts an access.
A similar situation can arise with equal? if we adopt your proposed change
to equal?.  Also, with the original semantics, we can reasonably require
that the error be caught even in unsafe mode, since the check occurs at
record-type creation time and not on each record access and mutation,
which increases security if we combine separately compiled modules.

Both models are legitimate points in the design space, but after having
used nongenerative types with the semantics of the original proposal,
I appreciate the creation-time error messages.

> > Presumably,
> > an interactive Scheme system needs to offer some way of "starting from
> > scratch" (as DrScheme), or undefining a non-generative record type
> > that's in the system, in the same way as a Scheme system might offer a
> > way of removing existing bindings (as Scheme 48).  I'm not sure that
> > part needs to be standardized---but it could, as part of the
> > procedural interface.
>
> So when you remove a UID-based record type and add a new one with the
> same UID, how do you provide good error messages when old instances are
> used? Doesn't this get you back to where you started?

If you're really starting from scratch, there won't be any old instances.
In other cases, the mapping for the UID to the associated rtd would
presumably have to be retained at least until the last instance of the old
record type is reclaimed, even if the introduced identifier bindings have
been eliminated.  But we're probably talking about implementation-specific
functionality which will have implementation-specific semantics.

> More generally, with UID-based record types and a requirement to signal
> an error, UID-based record types become a resource that can't be GCed.
> Although we know how to deal with non-GCable resources, I believe that
> the best strategy is to avoid them when possible.

I agree in principle, but I don't think it's a big problem in this case.

Kent