[R6RS] revised draft of record srfi

[William D Clinger]

Corrections to the latest draft of the records SRFI:

Rationale, second paragraph:
"manipuation" should be "manipulation"
"explicity" should be "explicitly"

Specification of make-record-type-descriptor, fifth paragraph:
The first occurrence of eq? within this paragraph should be
eqv?, because non-equivalence under eqv? implies eq? but not
conversely.  (You could try to argue that the rest of that
paragraph implies non-equivalence under eqv?, but you can't
really argue that without some sort of closed-world assumption,
e.g. that make-record-type-descriptor is the only way to create
a record type descriptor.)

Specification of record-constructor:
Since "the types handled specially by equal?" is open-ended,
with nothing to prevent equal? from handling *all* non-R5RS
types specially, the second paragraph of this spec is equivalent
to saying that "Two records...are equal according to equal? iff
they are eq?, provided they are not one of the exceptions to that
rule."  That's pretty silly, IMO.

I think it would be better to say something like

    If <VAL>rtd</VAL> describes an opaque record type, then
    the values created by such a constructor are not considered
    to be records; see the specification of record? below.

    Any two records created by such a constructor are equal
    according to equal? iff they are eq?.  Furthermore any
    record <VAL>r1</VAL> satisfies (eqv? <VAL>r1</VAL> <VAL>r1</VAL>).
    This does not imply (eq? <VAL>r1</VAL> <VAL>r1</VAL>).

The business about eqv? not implying eq? for records could be
removed, in which case we should remove the last sentence of
the above paragraph and change the eqv? in the previous sentence
to eq?.  (Notice that we can't make eqv? imply eq? for the values
returned by constructors for opaque types without restricting
the boxing/unboxing optimizations that the R5RS is so carefult
to allow.)

Specification of record-predicate:
Since the record constructor for an opaque type does not return
a record, this spec should say

    Returns a procedure that, given an object obj, returns #t
    iff obj is a value created by (record-constructor rtd).

Specification of record-accessor:
Similarly this spec should say

    Given a record-type descriptor rtd and a field-id argument
    that specifies one of the fields of rtd, record-accessor
    returns a one-argument procedure that, given a value created
    by (record-constructor rtd), returns the value of the selected
    field of that value.

Specification of record-mutator:
Similar this spec should say "given a value r created by
(record-constructor rtd) and an object obj, stores obj within
the field of r specified by field-id."

Specification of define-type:
I don't know what the spec means by "create identical bindings".
In Scheme, most bindings map identifiers to locations; is the
requiring the same locations to be used for every evaluation of
a local non-generative type definition?  If so, then the
non-generative definition is effectively global, and it would be
useful to say that.  This would be the first example in Scheme
of a local binding form that creates global bindings.

Implicit-Naming Syntactic Layer:
"a define-type form that conforms to the syntax of the
implicit-naming layer also conforms to the syntax of the
explicit-naming layer" is wrong; it's the other way around.
I also wonder whether "any definition in the explicit-naming layer
can be understood by its translation into the implicit-naming layer"
is really what was intended; it's true, but the other direction
is also true and is more enlightening.

This is as far as I have time to read today; gotta go.

Will