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 [email protected] http://per.bothner.com/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
