[I'm not speaking for the editors, of course.]
Andre van Tonder <andre_at_het.brown.edu> writes:
> No rationale is given for having the library (r6rs enum) in the
> report. Unless there is a compelling rationale, it is suggested that
> the library be dropped.
Let me suggest that the main failing is that the rationale isn't
stated. Let me describe what a possible rationale in the upcoming
rationale document might hypothetically say:
Many procedures in many libraries accept arguments from a finite set,
or subsets of a finite sets to describe a certain mode of operation,
or several flags to describe a mode of operation. Examples in the
R6RS include the endianness for bytes-object operations, and file and
buffering modes in the I/O library. As the mandate of the R6RS is to
foster portable and readable code, it makes sense to offer a default
policy for dealing with such values. (Much as records do for compound
values, or multiple values for procedure computing several values.)
Moreover, as noted in am earlier formal comment, representations of
sets from a finite set of options should offer the standard set
operations, as they tend to occur in practice. (One such set
operation is the complement, which makes lists of symbols a less than
suitable representation, by the way.)
Different Scheme implementations have taken different approaches to
this problem in the past, which suggests that a default policy does
not merely encode what any sensible programmer would do anyway. Given
how often possible uses occur, it makes perfect sense to standardize
this particular aspect of interface construction. In fact, I would
argue that such policy-describing libraries are considerably more
valuable *in the standard* than libraries providing "pure
functionality" such as the hash tables, which could just as well live
in SRFI. (Note that I am not arguing for removing the hash tables
from the report. But they could certainly be elided with less, namely
no, consequences for the rest of the report than the enumerations.)
> - there is no widespread prior usage experience of enumerations.
> - it seems to be an ad hoc encapsulation of accidental functionality
> used in the implementation of other libraries.
There is plenty widespread prior usage, in the forms of ad-hoc uses of
symbols or libraries offered by individual implementations. As such,
the library interface went through a careful (possibly flawed, as
always) design process with a number of iterations.
> - it is unclear what sets enumerations apart from a whole plethora
> of excluded possible libraries that may have been as useful or
> more useful.
That is certainly the case, but the same could be said for almost any
library included in the report.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Thu Nov 02 2006 - 06:41:16 UTC