[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
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)? 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))

whereas

  (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 the document.

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 Scheme)...

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.

Regards
Andre