[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Open issues for SRFI 113
- To: srfi-113@xxxxxxxxxxxxxxxxx
- Subject: Re: Open issues for SRFI 113
- From: Kevin Wortman <kwortman@xxxxxxxxx>
- Date: Sat, 07 Dec 2013 20:35:23 -0800
- Delivered-to: srfi-113@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mZQ9T7dbcWrJ4AS7N6KX9ZLo6suSbGN+cpnPWR/2RHo=; b=YT0UCdrIC3LvxJS1qYvUbx8yU4EN7/C9vTYWrVFKL7Gs6I57AD1O2xf1k4tdgDHsn1 tUDvUvsKRNvGqus+Gh6Td3yg6d3cL0DIR6VvyXM6S8l2HrxhIC2zzv0sHXHL5yYbluaR lODBqSnC9SGp9tuAWUmiMmitzUMrSsd1NVhADHjYTWS11CvDfMtG7+LxXTMlmaWSMmbl YVEx6sSz+HLJ/nhnil7pYENRoqMLbUItKmQcv3gi8lkGcEgTYr/MDtEQS4TcvbBTSsgc E1VmPyGUBRQia0nFMmjfuTlNQjh4nuvMcx/UnTsEbtMq0K/8iRkpF9JOj6Tofci6yFzA Es3w==
- In-reply-to: <20131204043726.GF22362@mercury.ccil.org>
- References: <20131204043726.GF22362@mercury.ccil.org>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
> 8. Should we switch to unique enum objects rather than symbols?
> Symbols are all distinct from one another, and are convenient to use,
> but it's not possible to ask which enum-set a symbol belongs to, for it
> may belong to more than one.
I think symbols are best.
> 12. Should we stick to just comparators, or also allow equality
> predicates? SRFI 114 provides comparators for `eq?`, `eqv?`, `equal?`,
> `string=?`, and `string-ci=?`, which are the Big Five. Hash tables need
> to accept equality predicates for backward compatibility, but there is
> no real compatibility issue for sets.
I think it should be comparators only. Otherwise there is an implicit
union type of comparator-or-equality-predicate. Code that depends on
this SRFI, or mimics it, would also need to deal with the
comparator-or-equality-predicate type, so code handling that concern
would be scattered all over the place. Creating a comparator is easy so
I think it's reasonable to expect client code to do that.
> 13. Should we switch to six libraries (sets, bags, integer sets,
> character sets, enum sets, and set-bag conversion), or stick with a single
> library? (This is not about dividing the SRFI itself.) The only reason
> to do this would be to minimize namespace pollution and load space:
> if you don't need bags or charsets, you wouldn't have to have them.
> On the other hand, the whole package is only about 2 KLOC.
In my use cases the time and effort that it takes programmers to find
and import multiple fine-grained libraries is far costlier than the time
it might take a Scheme environment to load a single coarse one, so I say
stick with one library.
> 14. Should we add a cursor API similar to SRFI 14's? This would allow
> stepping through the elements in a fixed order. It wouldn't make much
> sense for general sets or bags, but might be handy for character sets
> (via SRFI 14), integer sets, and enum sets.
This can be deceptively complex with mutable structures, since all the
interactions between mutative operations and pre-existing cursors need
to be defined precisely.
If we do go down this route I would advocate using streams (lazy
sequences) for this purpose rather than inventing a new cursor API.
Presently one could iterate through a set by converting it to a list and
using established list iteration methods, admittedly with O(n) space
overhead. Are there use cases where this would be inadequate?