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.
On 12/08/2013 10:05 AM, John Cowan wrote:
>> [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.
Yeah I think collisions with these names are unlikely, and if they were
to occur, the import syntax has clean ways of handling it.
>> [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.
That's OK, although it makes some intuitive algorithms impossible to
implement. For example a straightforward way of computing the set
difference (A - B) destructively is
for each element x in set A:
if x is in set B:
delete x from A
If the "delete x from A" operation invalidates the "for each element x"
cursor then you're out of luck.
Then again, insisting that live cursors stay valid is a heavy
implementation burden that adds a lot of complexity and effectively
prohibits some data structures.
IMO the better part of valor is to try to get away with not having
cursors into mutable data structures. Almost all use cases can already
be handled by the "Mapping and folding" procedures.
Kevin Wortman