Formal comment #70 (simplification) No rationale for (r6rs enum) Reported by: Andre van Tonder Component: other Version: 5.91 Pages : 118-120 Summary 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. Description In the absence of a rationale, it is difficult to judge whether this library is really essential. In contrast to most of the other libraries included in the report, I do not think enumerations were part of the r6rs mandate. there does not seem to be a general feeling in the community that enumerations are essential and should be standardized. it is unclear what sets enumerations apart from a whole plethora of excluded possible libraries that may have been as useful or more useful. 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. I do not personally know a sufficiently strong reason to include this library in the report. I do not deny that enumerations may be useful, but since the report is already regarded by many as too large, perhaps this library might be profitably excised. Suggestion Perhaps drop this library. Alternatively, it may be helpful to provide a compelling rationale for including it. RESPONSE: The following rationale is the basis for the decision to include enumerations: 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 procedures computing several values.) Moreover, as noted in an 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.