[r6rs-discuss] [Formal] Drop enumerations library?

From: AndrevanTonder <andre>
Date: Thu Nov 2 09:17:19 2006

On Thu, 2 Nov 2006, Michael Sperber wrote:

> 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,

But endiannesses are symbols in the current version, so the abstraction is
illusory in that case. The document states

"(endianness big) and (endianness little) evaluate to
  the symbols big and little, respectively. These symbols
  represent an endianness, and whenever one of the procedures
  operating on bytes objects accepts an endianness as
  an argument, that argument must be one of these symbols."

In other words, one could write, e.g.,

    (bytes-u16-ref b 14 'little)

using QUOTE to break the abstraction by forging the enumerated
values. I happen to think that symbols are just fine here, but if I had to
build a safe "endianness" abstraction, I would think that it would be better to
use generative objects that cannot be forged by "quote". Such an abstraction is
trivial to build in terms of records, without an enumeration library.

   (define-record-type endianness-value (fields (immutable integer)))
   (define (endianness-big) (make-endianness-value 0))
   (define (endianness-little) (make-endianness-value 1))

I am not advocating this for endianness, but this is i.m.o. a safer abstraction,
and I like the fact that it is procedural, rather than syntactic, better.

> 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" ...

I would disagree with the philosophy that libraries are needed for policy.
Policy is often better set by example. If programmers think the "endianness"
example is good convention, they will follow it, as they have followed many
conventions from r(<=5)rs.

> There is plenty widespread prior usage, in the forms of ad-hoc uses of
> symbols or libraries offered by individual implementations.

But "endianness" values are still symbols...

>> - 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.

It can perhaps be said of some, but not any. In my view, there has been some
widespread consensus in the community for the need of standardizing records and
procedural macros (though disagreement on the particulars). I don't think this
can be said for enumerations.

Cheers
Andre
Received on Thu Nov 02 2006 - 09:13:41 UTC