Hi,

I have couple of comments for this SRFI:

- What's the significant difference amoung the other record related SRFIs,
  especially SRFI-99? This is 6th record relared SRFI, so it would be nice
  to have why this SRFI is needed. (To me, it seems almost identical to
  SRFI-99 but just a bit of procedural difference)
- The SRFI says, it's extension of R7RS small's record type. Does this mean
  a record type which is defined with define-record-type in (scheme base)
  can be extended by this SRFI's define-record-type?
- <parent> on Syntax section is specified to be a <keyword>. Shouldn't it be
  <type name>? And also specify <type name> will be bound to macro keyword
  instead of implicitly saying it on Rationale? (though, <macro use> requires
  <type name> to be a macro so maybe not)
- Above implicit indication and the description of <type name>, I can read
  record-type descriptor is a macro, is it intentional?
- In description of <macro use>, if a record-type description doesn't have
  parent, then the expanded form would have #f as <parent> or it'd be ommited?
- I think make-record-type-predicate is ugly since it requires eval. Why
  don't you use implicitly defined type record-type descriptor? (Of course,
  if it's not a macro though)
- What would happen if make-record-type-predicate gets not yet defined record
  type as its first argument?
- How does the field-vector, argument of make-record, look like? Is this a
  vector of field values or the element contains filed name as well?

This might be a bit off topic. The SRFI seems to require a storage which is
used to lookup record-type descriptor by either <type-name> or predicate. I
think it's ugly since it also means single namespace (or library) to manage
these information. (Maybe there's a better way not to do like that).

And this might be releated to the first bullet of the comments, why not using
R6RS record without implicit field accessor or facility reduced?

Cheers,

--
_/_/
Takashi Kato
E-mail: ktakashi19@gmail.com