On 05/19/2013 10:29 PM, John Cowan wrote:
> The first is on sets, bags, integer sets, and enumeration
> sets.  The current editor's draft is in SRFI format at
> <http://ccil.org/~cowan/temp/srfi-sets.html>.  Send feedback to either
> list or directly to me.

FYI: Kawa's enumerations are conceptually different: An enumeration
type is a class, and each enumeration value is a distinct
instance of that class, rather than a generic symbol.

http://www.gnu.org/software/kawa/Enumerations.html

There are advantages and disadvantages of the two approaches.
An advantage of the proposal (and R6RS) is that an enumeration
literal is just a symbol.  A disadvantage is that the API is
a bit more complex, since you have to explicitly mention the
enum-type in many of the functions.  Another disadvantage is
performance: For example for the enum-set function each
element needs a hash lookup.

It might be reasonable for Kawa to implement the proposed enum-type
using an anononymous enumeration-type.  It would make this a bit
more elegant if the standard added a define-enum form:

(define-enum colors (red blue green))

would be equivalent to:

(define colors (make-enum-type '(red blue green)))

but it associates the print-name "colors" with the type.
Plus it may be easier to implement efficiently.

Then: (enum-set colors 'green 'blue)
would be equivalent to: (colors-enum-set (colors 'green) (colors 'blue))
assuming some color-enum-set function.  The lookup (colors 'green)
can be then be optimized, avoiding a runtime lookup.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports