[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Initial comments

Hi Will,

I agree that there is room for a simpler record system that is, as far as possible, compatible with the R6RS. This SRFI looks like a good step in this direction.

The SRFI says: "It is not possible to design APIs that interoperate well with both the R6RS syntactic and procedural layers, because the R6RS syntactic layer uses a fundamentally different notion of record type than the R6RS procedural layer." This statement would appear to be a significant restriction on the scope of the SRFI. I would suggest that it be backed up with an explanation or example or citations.

I am very uncomfortable with libraries that, to a large degree, are subsets of the functionality of a other libraries, but use different names for almost identical procedures. As I get older needless memorization vexes me more and more. I ask, why should I have to remember that the R6RS prefers "record-type-descriptor" but this SRFI prefers "rtd". Please rename all of the procedures in the same style as the SRFI.

Your example implementation of rtd-constructor offers a great example of the dangers of this renaming. You refer to a "record-type-all-field- names" procedure. No such procedure exists in the SRFI or the R6RS. I suspect you mean either "rtd-all-field-names" or "record-type-field- names".

The description of the behaviour of "eq?", "eqv?", and "equal?" in the SRFI is very different from the description in the R6RS. I believe they are equivalent, but then I also do not understand why the fourth clause in section 6.1 of the R6RS Standard Libraries document is necessary, so who am I to offer an opinion? Is it your opinion that the behaviours are equivalent?


Alan Watson