At Sun, 12 Sep 2004 16:49:25 -0400 (EDT), Andre van Tonder wrote:
>
> Hi Jorgen, thanks for your comments
>
> On Sun, 12 Sep 2004, Jorgen Schaefer wrote:
>
> > 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?
>
> So as to permit omissions without running into ambiguities (if you agree
> that the possibility of ommissions is a good thing).  For
> example, with the SRFI-9 order, in
>
>    (define-record foo bar)
>
> are we omitting the constructor or the predicate, or both (note that
> SRFI-57 allows the constructor clause and field clauses to be
> identifiers)?

We could allow #f in place of the constructor or predicate when you
don't want to specify it (I'm pretty sure I've seen a Scheme that does
this).

> With SRFI-57, we can write
>
>    (define-record foo bar ()) - bar is constructor, no fields or predicate

(define-record-type foo bar)

>    (define-record foo () bar) - bar is predicate, no fields or constructor

(define-record-type foo #f bar)

There's no ambiguity and we preserve backwards compatibility.

In general I agree with Jorgen (and Olin Shivers argument on the
original SRFI-9 list) that it would be nice to preserve backwards
compatibility where possible.  Thus if SRFI-57 uses
"define-record-type" and doesn't change the order of parameters, then
any existing SRFI-9 code can run unmodified in SRFI-57.  True it's
just a matter of providing syntax wrappers to define
define-record-type in terms of define-record, but you end up with
namespace clutter and increasing amounts of legacy wrappers when just
a little care in the initial design can obviate the need for this.

> ...you have a point.  While I specified matching on records (and
> only on records - the rest is not required) because without it, records
> are much less useful to me, there certainly is a strong argument for
> splitting matching off into a separate SRFI, and I *might* do that if I
> can summon up the required mixture of masochism and ruthlessness for it.

Please do!  Your implementation is beautiful, but matching is an
entirely orthogonal concept to records and I don't think you should
let the implementation influence the design.

--
Alex