Greetings,
and thanks for this SRFI - I like the ideas very much. Anyways,
I'm going to nag about the parts I don't understand.

My main problem is the relationship between SRFI-57 and SRFI-9. As
far as features are concerned, this SRFI looks like a perfect
extension to SRFI-9, yet it doesn't try to stay compatible with
SRFI-9. Is there a good reason for changing the argument order and
makeup of the DEFINE-RECORD macro from that specified in SRFI-9?
I.e. that the predicate comes last, and that the fields are
specified as a list of field specifiers instead of specifiers as
separate arguments?

If there's a good reason, please add that rationale to the SRFI
document. If not, I'd greatly appreciate switching to the SRFI-9
syntax.

The subtyping part of the SRFI is wonderful, but I'm missing a
specification on what happens if someone subtypes two records with
the same field name, but different accessors, or two records with
the same accessors, but different field names.

Also, would it be possible to renamed UPDATE and EXTEND to
UPDATE-RECORD and EXTEND-RECORD? I think those names are clearer.

Now on to the last part, the only part of the SRFI I absolutely
don't like: The pattern matching facility. As you correctly say,
it is outside the scope of SRFI-57 to specify a full-featured
pattern matching facility - please don't try to specify a
half-featured one, then. The pattern matching is not an inherent
part of the record facilities, especially since it enforces one
type of pattern matching. It would be much more useful to specify
a full-fledged matcher in a separate SRFI.

To conclude this email, I'd greatly appreciate this to be changed
to a pure extension of SRFI-9, so that it's backward-compatible in
all respects, and intended as such.

Thanks for reading,
    -- Jorgen Schäfer

--
((email . "xxxxxx@forcix.cx") (www . "http://www.forcix.cx/")
 (gpg   . "1024D/028AF63C")   (irc . "nick forcer on IRCnet"))