[R6RS] Enumerations proposal pre-draft

[Michael Sperber]

Having read Will's proposal, I still prefer an enumerations mechanism
that introduces new types for enumerations.  I only summarized the
rationale on the phone, so I figured it might be a good idea to write
it up.  (As always, all remarks referring to optimizing compilation
are relative to my limited knowledge.  Please correct me where I'm
wrong.):

- Writing (color purple) makes it explicit what enumeration the color
  comes from.  We could use some convention for symbol naming, but the
  proposal codifies the convention, and forces people to use it.

- Macro expansion performs a certain degree of static checking in that
  it will often find typos.  I.e., (color purpel) will raise an
  expansion-time error, whereas 'purpel will not.

- Having a new type allows for very fast dynamic type checking.
  Moreover, I suspect that it at least simplifies compile-time
  checking for compilers that already have the infrastructure for
  tracking record types through their flow analyses, but not sets of
  symbols.

- The mapping to integers is much faster than with symbols.  This
  could also be exploited to produce very fast code for a case
  distinction, via tables or binary search.  (This may also be
  possible for symbols, but I don't see how.)  This might justify
  adding an enum-case form that allows you to do this:

(enum-case c color
  ((purple blue) 'bluish)
  ((red orange) 'reddish)
  (else 'ugly))

  It also enables a straightforward and fast implementation of enum
  sets via bit strings.  (Of course, that's possible for symbols as
  well, but you always have to figure out the indices.)

- This extends straightforwardly to finite types, where more fields
  can be added to the enumeration values.  See the description of
  `define-finite-type' here:

  http://www.s48.org/1.3/manual/manual-Z-H-7.html#node_sec_5.11

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla