[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility, pattern matching and some small things
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
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)? With SRFI-57, we can write
(define-record foo bar ()) - bar is constructor, no fields or predicate
(define-record foo () bar) - bar is predicate, no fields or constructor
Also, fields are in a list because a field clause may be an indentifier,
e.g. we can unambiguously write
(define-record node (left right))
(define-record node left right)
would be ambiguous (e.g. is left the constructor or the first field?)
The syntax specified here is the most concise I could come up with
that allows one to leave out all possible combinations of non-essential
elements without ambiguity.
Please also refer to the SRFI-9 list for the philosophy of the author
with repect to extensibility, which generated quite a bit of discussion.
Notice that the current SRFI specifies DEFINE-RECORD instead of the
SRFI-9 DEFINE-RECORD-TYPE, so legacy code using SRFI-9 can be adapted by
adding a simple macro defining the latter in terms of the former.
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,
Okay, it would make sense to add some clarification in the document.
If you mean
(define-record foo ((bar foo-bar)))
(define-record baz ((bar baz-bar)))
(define-record (foo-baz foo baz) ((bar foo-baz-bar)))
then of course any instance fb of foo-baz is an instance of both
foo and baz, so that foo-bar and baz-bar will both work on fb, returning
the bar field. The accessor foo-baz-bar will return the bar field
of any instances of foo-baz or subtypes of foo-baz.
or two records with
the same accessors, but different field names.
If here you mean
(define-record foo ((bar foo-bar)))
(define-record baz ((baz foo-bar)))
then, as in any define-... forms, since later bindings replace earlier
bindings, foo-bar will now work on instances of baz and not any longer on
instances of foo. It would make sense to add a warning to this effect to
Also, would it be possible to renamed UPDATE and EXTEND to
UPDATE-RECORD and EXTEND-RECORD? I think those names are clearer.
That would make sense. Perhaps, for uniformity with convention,
RECORD-UPDATE and RECORD-EXTEND instead.
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,
Although I don't quite agree with this (e.g. consider the
symmetry constructing/matching, representing algebraic datatypes with
records, or look at Andrew Wright's et al's work on soft typing for
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.
...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.
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.
As I noted above, legacy code can be adapted with a simple macro
defining DEFINE-RECORD-TYPE in terms of define-record. The only way to
fulfill your request otherwise would be to drop support for omissions,
which I would be reluctant to do.