[R6RS] Enumerations proposal pre-draft

[William D Clinger]

Here is a question concerning define-syntax, syntax-case,
and gensym:  How do the editors expect macros such as the
following to be implemented using the R6RS macro system?

With the current draft of the enumerations proposal,

  (define-enumeration color
    '(black white purple maroon)
    color-set)

needs to expand into something like

  (begin
    (define color-universe:obscurely-named:should-be-non-forgeable
      (make-enumeration '(black white purple maroon)))
    (define-syntax color
      (syntax-rules (black white purple maroon)
       ((_ black) 'black)
       ((_ white) 'white)
       ((_ purple) 'purple)
       ((_ maroon) 'maroon)))
    (define-syntax color-set
      (syntax-rules ()
       ((_ symbol ...)
        ((enum-set-constructor
          color-universe:obscurely-named:should-be-non-forgeable
         (list (color symbol) ...))))))

There are several issues here:

* Obviously define-enumeration can be used only in a definition
  context.  That's fine.

* If define-syntax can appear only at top-level or library-level,
  then define-enumeration can appear only at those levels.  The
  current draft of syntax.html also allows define-syntax at the
  level of internal definitions.

* The define-enumeration macro must generate a unique, fresh,
  ideally non-forgeable name.  With the macro system we are
  considering for R6RS, uniqueness and freshness can only be
  accomplished by using syntax-case, if at all, and it even
  less clear whether non-forgeability can be accomplished.

* Uniqueness and freshness can be accomplished by syntax-case
  only if syntax-case transformers can change the state of the
  macro-expansion-time world in which they execute.  It is not
  clear whether this is allowed by the current draft of the
  syntax proposal, or whether it should be allowed.

* The current specification of generate-temporaries says the
  temporaries are "guaranteed to be unique, i.e., different
  from all other identifiers", but that is a vacuous statement,
  true of every identifier.

* What we need to know is whether there is a way to generate
  an identifier that will never be generated by any other call
  to generate-temporaries, and cannot be forged (e.g. by passing
  a string to string->symbol).

* The last paragraph of section 3.9 suggests that the identifiers
  returned by generate-temporaries are forgeable, for there does
  not seem to be any guarantee that the temporaries generated
  during the expansion of one form or library will be distinct
  from the temporaries generated during the expansion of another.

* In fact, some existing implementations of syntax-rules generate
  the same sequence of temporaries for each form expanded, and
  this is legal under the R5RS semantics.  If this is supposed
  to be illegal under the R6RS semantics, then we need an R6RS
  semantics that answers questions of this sort.

Will