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.
Alan Watson wrote: > 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. That is a general consequence of the R6RS design, not a peculiarity of this particular SRFI. > I would suggest that it be backed up with an explanation > or example or citations. Okay, will do. > 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". The procedural and inspection layers of SRFI 99 are fully compatible with the corresponding layers of the R6RS record system, so it would not be unreasonable for some programs to use them together. Systematic use of the "rtd-" prefix in SRFI 99 prevents clashes with the names defined by the corresponding layers of the R6RS, and reduces confusion between SRFI 99 procedures and those of the R6RS: If a procedure's name begins with "rtd-", then it is part of the SRFI 99 API, not the R6RS. > Please rename all of the procedures in the same style > as the SRFI. Aside from the error in the example that you pointed out, I believe all of the procedures in SRFI 99 are already named in the same consistent style. > 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? No, the behavior specified by the R6RS is not quite equivalent to the behavior specified by SRFI 99, but that's because, in my opinion, the fourth bullet item of the R6RS specification is incorrect. Suppose, for example, that r is a record, and a is a record accessor for which r is not an acceptable argument. Then the results of applying a to r on two separate occasions may consist of exceptions whose condition objects are not the same in the sense of eqv?, but that should not force (eqv? r r) to return false. Aside from that, I think the behavior specified by the R6RS is equivalent to the behavior specified by SRFI 99, but the SRFI 99 specification is clearer and simpler. Will