Re: Backward compatibility, pattern matching and some small things

[Andre van Tonder <andre@xxxxxxxxxxxxxxxxx>]

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