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

Initial comments

This page is part of the web mail archives of SRFI 99 from before July 7th, 2015. The new archives for SRFI 99 contain all messages, not just those from before July 7th, 2015.

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