[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Seeking review of sets and hash tables proposals
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.
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.
Scheme-reports mailing list