From: Richard Kelsey <xxxxxx@research.nj.nec.com>
      From: Olin Shivers <xxxxxx@shivers.ne.mediaone.net>

      First, put the field-spec's in their own list.

      This allows future SRFIs to extend this SRFI's syntax with extra items,
      such as Dybvig's meta-programming hooks, or "method definitions"
      for generic operations such as printing or disclosing.

   I would rather keep this SRFI's syntax simple and let future SRFIs
   do whatever they want.  There are many different variants of
   DEFINE-RECORD-TYPE; it isn't possible to be compatible with all
   of them.

Sure, but it's simple to segregate the field-specs and allows future
SRFIs an easy way to extend the form.

I am generally suspicious of the attitude I see on the SRFI discussion lists
of saying: let's not argue about this issue; this is just one SRFI; other
alternates will come along. That is, of course, true. And real differences in
approach or style *should* be accommodated by different SRFIs. But too many
SRFIs for a given feature can be a bad thing.  It's better to make an effort
to make each SRFI represent some consensus, and to hash out a design that is
as much as possible The Right Thing. The more people sign up to live with a
given SRFI, the better off we are: there's less profusion of different API's
and syntaxes, and it's easier to port code.

If you can build in a syntactic hook for SRFI-9 to be easily extended to later
proposals, then that's a good thing.

Segregating the field specs into a list allows for two kinds of extension
compatibility:
    - Consider an extension of SRFI-9 that puts non-essential information
      following the list of field specs, such as introspection or debugging
      or printing specs. Code written to this later spec can be run using an
      implementation of SRFI-9 that just ignores parts of the form following
      the field-spec list.

    - Code written to SRFI-9 spec can be run in a system that provides
      an extended DEFINE-RECORD-TYPE with no changes or porting support.
      This is the real win.

All you have to do is allow for the possibility of later extension in your
syntax design.
    -Olin