Hi Will,

I agree that there is room for a simpler record system that is, as far
as possible, compatible with the R6RS. This SRFI looks like a good
step in this direction.

The SRFI says: "It is not possible to design APIs that interoperate
well with both the R6RS syntactic and procedural layers, because the
R6RS syntactic layer uses a fundamentally different notion of record
type than the R6RS procedural layer." This statement would appear to
be a significant restriction on the scope of the SRFI. I would suggest
that it be backed up with an explanation or example or citations.

I am very uncomfortable with libraries that, to a large degree, are
subsets of the functionality of a other libraries, but use different
names for almost identical procedures. As I get older needless
memorization vexes me more and more. I ask, why should I have to
remember that the R6RS prefers "record-type-descriptor" but this SRFI
prefers "rtd". Please rename all of the procedures in the same style
as the SRFI.

Your example implementation of rtd-constructor offers a great example
of the dangers of this renaming. You refer to a "record-type-all-field-
names" procedure. No such procedure exists in the SRFI or the R6RS. I
suspect you mean either "rtd-all-field-names" or "record-type-field-
names".

The description of the behaviour of "eq?", "eqv?", and "equal?" in the
SRFI is very different from the description in the R6RS. I believe
they are equivalent, but then I also do not understand why the fourth
clause in section 6.1 of the R6RS Standard Libraries document is
necessary, so who am I to offer an opinion? Is it your opinion that
the behaviours are equivalent?

Regards,

Alan
--
Alan Watson
http://www.alan-watson.org/