[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Open issues for SRFI 113
Kevin Wortman scripsit:
>  I think symbols are best.
>  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.
I agree. My only reservation is that hash tables will have to support
naked equality predicates for backward compatibility with SRFI 69 and
R6RS. But I think we can allow them in that SRFI and deprecate them
instead of allowing them anywhere. Removed.
>  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.
It's not so much time-to-load as namespace pollution. The library as
currently specified introduces 238 identifiers. Admittedly they are
named according to a fairly small number of patterns, which hopefully
will make collisions unlikely. I'll leave things as they are.
>  This can be deceptively complex with mutable structures, since all the
> interactions between mutative operations and pre-existing cursors need
> to be defined precisely.
Or just say, as Java does and as I do in HashTablesCowan, that the effect
of mutating a hash table with live cursors is undefined.
> If we do go down this route I would advocate using streams (lazy
> sequences) for this purpose rather than inventing a new cursor API.
I'll hold off on anything like that for this SRFI then until we get
to streams. Closed.
> 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?
Character sets in the Unicode domain are an obvious counterexample.
In Unicode 6.3, for example, (char-set->list char-set:letter) returns
a list of 89,843 characters. Still, we could leave that functionality
just in SRFI 14.
Overhead, without any fuss, the stars were going out.
--Arthur C. Clarke, "The Nine Billion Names of God"
John Cowan <cowan@xxxxxxxx>