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

Re: [oleg@xxxxxxxxx: Minor quibbles on the latest draft]

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



Scot:
> Jens Axel:

My intution says that it's relatively seldom one needs to use
more than one implementation at a time (but it can happen).

I see this more frequently than you'd think. Its not so much that *you* would write code that uses two collections of the same type, but it happens frequently when joining in modular code from more than one subsystem, especially where that system publishes an API which you write for where you need to be deliberately unaware of certain implementation details.
You have a point.

This is especially important for maintenance of the resulting system. Especially as Scheme systems start (and continue) to offer compiled modules, programmers or sysadmins may want to upgrade package Foo. If Foo changes its selection of the underlying set collection, it would be onerous to require all packages that depend on it to be modified at the source code level to remain compatible.

Yes - but isn't it the role of the module system to take care of that?

[I'm for the sake of argument ignoring the fact that we don't have a common module system.]

As an afterthought: It wouldn't be too difficult to support both solutions in systems
with a module system.

--
Jens Axel Søgaard