[R6RS] record types and UIDs

[Matthew Flatt]

At Sat, 25 Feb 2006 12:01:38 +0100, Michael Sperber wrote:
> > The SRFI doesn't say what happens if the other arguments not all equal.
> 
> That's not true---it says:
> 
> >> If a call with the same uid differs in any argument, an error is
> >> signalled.

You're right, of course. I couldn't find it for some reason.

> > Would it make sense to change the `uid' argument to a `uid-prefix'
> > argument that's combined with all the other arguments to produce the
> > true UID? Then there's no question of incompatible UID mappings.
> 
> It's a tricky question.
> 
> Imagine I work in an interactive system and I define a non-generative
> record type, create a bunch of records off that type, and then make a
> change to the record type and re-evaluate it.  If the system lets me
> do it, as you propose, and I pass the old records into procedures that
> are meant for the new type, errors are signalled.  Now, the system
> needs to explain to the user what's gone wrong.  That's hard enough if
> the names of the record types are the same---if the uids are the same,
> I think it'll be worse.  (I've certainly often been confused by
> exactly that situation.)

This is a great example (thanks!), but it convinces me of the opposite
conclusion: that UID prefix is really much better than a UID.

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?

> 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?

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.

Using a UID prefix instead of a UID makes all record types GCable, it
doesn't seem to introduce error-reporting problems that aren't there
otherwise, and it allows programmers in an interactive setting to
conveniently redefine bindings associated with a UID-prefixed record
type.

Matthew