[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility, pattern matching and some small things
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
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
> 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.