[R6RS] non-opaque record equality

dyb at cs.indiana.edu dyb at cs.indiana.edu
Sat Feb 25 17:54:01 EST 2006


> Kent wrote:
> >   (equal? (f) (f))      nonterminating if procedures are records,
> >                         #f otherwise
>
> If procedures were records, wouldn't they be *opaque*
> records?  In which case the recursive comparison would
> be eqv?, and the equality comparison would terminate.

That's certainly something we could declare, but I'm not sure we really
want to require all implementations to treat procedures and other built-in
types as opaque.  Will implementations also have to treat hash tables
or other library datatypes as opaque?

> Another way of saying it is that representing procedures
> as non-opaque records would be illegal if equal? compares
> all such records recursively, because the R5RS requires
> equal? to use eqv? when comparing procedures.

R5RS says:

  {\cf Equal?} recursively compares the contents of pairs, vectors, and
  strings, applying {\cf eqv?} on other objects such as numbers and symbols.

If you take "other objects" to mean "all other objects", then records
are included, and recursively comparing records is illegal.  If you take
it to mean "some other objects", then it doesn't necessarily include
procedures, and recursively comparing procedures is legal.

In any case, that description was for R5RS, which had no records, and
we're talking about R6RS, which will, so we shouldn't hold ourselves to
the R5RS wording, however we interpret it.

> Another possibility is that we could require equal? to
> terminate on all arguments.  Judging by a discussion in
> comp.lang.scheme, it appears this is easier and more
> efficient than I had  believed when we last had this
> discussion.

This doesn't solve the issue unless we make built-in types opaque, since
equal? might still return #f in one implementation and #t in another
if equal? compares records recursively and built-in types are opaque
in one and not in another.  (Requiring built-in types to be transparent
doesn't help, by the way, unless we also constrain what goes into them.)

Kent



More information about the R6RS mailing list