propositions, oppositions, and some minor details campbell@xxxxxx 12 Sep 2004 23:00 UTC
I have a number of initial questions, comments, and opinions to make. (I sent a similar email a few days ago, but there were problems with my SRFI mailing list subscription, so it wasn't received yet; I hope the editors see this email first so they can not bother to send the other one.) First, my thoughts on the matter of syntactic details. With respect to compatibility with SRFI 9, I think it would just be easier if the predicate were mandatory. I don't see much of a reason to omit it, and, by mandating it, it removes ambiguity: it clearly delimits the type name & the constructor specifier from the fields. Also, I don't like the token for specifying mutability. I think it would be better to have a <field spec> nonterminal where the token for mutability is _not_ a symbol; I think it would also be a bit more consistent to allow a mutable field with an accessor but no separate modifier defined. This replacement <field spec> nonterminal would fix both problems, given some <mutability token>, e.g. #T/#F: <field spec> -> (<field label> [<accessor name>] [<mutability token>]) | (<field label> <accessor name> <modifier name>) The last syntactic detail that bothers me is the use of record types' constructors in the pattern matching. It would seem more sensical to me to use the record type names themselves, not their constructors; this would also solve the problem that required identifier macros -- which I am loathe to consider -- when defining the constructors so that they could be used as regular variable bindings, bound to procedures, as the specification specifies: they would no longer need syntactic information used in pattern matching. I also have a somewhat deeper semantic question: can SRFI 57 be used to define subtypes of record types defined with SRFI 9? My suggestion: an emphatic *YES*. I am also *vehemently* opposed to the completely unrestricted operator of reflection RECORD->SEXP. Reflection should either be completely expurgated -- as I'd prefer --, or, if you intend to include any at all in this SRFI, highly controlled by whomever defined the record type. For example, Scheme48 has a simple, controlled mechanism for disclosing the components of particular record types, though mostly for printing unreadable objects. I don't want to clutter this email describing it, however, unless requested; request if you want me to. A smaller issue that I brought up on c.l.s seemed to have been left unnoticed: record type equivalence seems to be based on name, not on identity of the record type. I believe this could be fixed by defining an extra variable when invoking DEFINE-RECORD for a token identifying the newly defined record type, and comparing against this, instead of symbolic names, in BUILD-MAKER. Regarding implementations, it is obviously not tractable for many Scheme implementations to implement DEFINE-RECORD as a syntax-rules macro of such extreme proportions; although I find it amazing that you wrote such a macro, I don't think it's practical, _especially_ not for implementations that implement syntax-rules by translating the expression into Scheme, compiling the Scheme, and then running that -- for _every_ use of syntax-rules. I believe it would be a good idea to provide an alternative implementation of DEFINE-RECORD in terms of even a non-standard macro system, such as the fairly widely implemented explicit renaming.* It would also be undoubtedly easier to maintain as the SRFI evolves than this gargantuan set of syntax-rules macros. Finally, it would also be good if an implementation were provided -- be it in syntax-rules or explicit renaming or anything, as long as it can be shown that it works -- that based records on the low-level record interface used internally by SRFI 9's implementation, because that is what most 'real' implementations will likely be based on. While I'm writing this, too, I may as well cast a vote for specifying pattern matching in a separate SRFI, presumably one that simply shares its reference implementation.