This page is part of the web mail archives of SRFI 9 from before July 7th, 2015. The new archives for SRFI 9 contain all messages, not just those from before July 7th, 2015.
From: Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> From: Olin Shivers <shivers@xxxxxxxxxxxxxxxxxxxxxxx> First, put the field-spec's in their own list. This allows future SRFIs to extend this SRFI's syntax with extra items, such as Dybvig's meta-programming hooks, or "method definitions" for generic operations such as printing or disclosing. I would rather keep this SRFI's syntax simple and let future SRFIs do whatever they want. There are many different variants of DEFINE-RECORD-TYPE; it isn't possible to be compatible with all of them. Sure, but it's simple to segregate the field-specs and allows future SRFIs an easy way to extend the form. I am generally suspicious of the attitude I see on the SRFI discussion lists of saying: let's not argue about this issue; this is just one SRFI; other alternates will come along. That is, of course, true. And real differences in approach or style *should* be accommodated by different SRFIs. But too many SRFIs for a given feature can be a bad thing. It's better to make an effort to make each SRFI represent some consensus, and to hash out a design that is as much as possible The Right Thing. The more people sign up to live with a given SRFI, the better off we are: there's less profusion of different API's and syntaxes, and it's easier to port code. If you can build in a syntactic hook for SRFI-9 to be easily extended to later proposals, then that's a good thing. Segregating the field specs into a list allows for two kinds of extension compatibility: - Consider an extension of SRFI-9 that puts non-essential information following the list of field specs, such as introspection or debugging or printing specs. Code written to this later spec can be run using an implementation of SRFI-9 that just ignores parts of the form following the field-spec list. - Code written to SRFI-9 spec can be run in a system that provides an extended DEFINE-RECORD-TYPE with no changes or porting support. This is the real win. All you have to do is allow for the possibility of later extension in your syntax design. -Olin