[R6RS] revised draft of record srfi

[William D Clinger]

Mike Sperber wrote:
> I'm not sure I follow you here.  I think Marc is saying that, if the
> R6RS specified that two records are equal? iff they are eq?, it would
> disallow [an example we want to permit]

My mistake.  Good catch, Mike.

I didn't realize the record? predicate would return true even
for opaque records.  One way to solve the problem would be to
make the record? predicate return false for opaque records.
I would favor that change.

I see you solved the problem by leaving the behavior of equal?
unspecified on records, except for eq? implying equal?.  Another
way to solve the problem is to say that equal? behaves the same
as eq? on records created by the constructor for a non-opaque
record type, and to leave the behavior of equal? unspecified
only for opaque records.

By the way, the SRFI should mention eqv? instead of eq?, because
the R5RS basically treats eq? as a fast but moderately broken
version of eqv?, and we should continue that tradition unless we
explicitly decide otherwise.

Kent wrote:
> gc-count actually *should* appear free.  It is the current gc-count as
> of when the record is created.

Had the value of gc-count been obtained by calling some procedure,
it wouldn't have looked like a mistake in the SRFI.  It didn't
occur to me that the current gc-count might be held in a global
variable; IMO that's pretty un-Schemely.

> zero also works (sort of) if we assume that gc counts begin at
> zero; the problem is that we can get an extra rehash if the actual
> current gc-count is greater than zero.

Zero works just fine.  The extra rehash occurs when the table is
empty, so who cares?  It's more important to make the example
easy to understand than to avoid the O(1) cost of rehashing an
empty table.

Will