[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Open issues for SRFI 113

This page is part of the web mail archives of SRFI 113 from before July 7th, 2015. The new archives for SRFI 113 contain all messages, not just those from before July 7th, 2015.



Kevin Wortman scripsit:

> [8] I think symbols are best.

Agreed; removed.

> [12] 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.

> [13] 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.

> [14] 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>