[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Initial comments
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
> 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