Soliciting comments on Edison

G'day all. As some of you know, I'm hacking up Edison. I'd like some suggestions on namespace issues. Note that at the moment, "Edison" has its own top-level name in the libraries document, and I'm happy for things to stay that way for now. First, an overview. Edison is a library of data structures, based around three main concepts: - A Sequence is any container where order is maintained (e.g. stacks, queues, deques, lists etc). - A Collection is a container where order is not maintained, or rather, is maintained by constraints on the ADT (e.g. sets, bags, priority queues etc). - An Association is a container which maps some key type to some data type (e.g. search trees, hash tables etc). The main feature of Edison which distinguishes it from other data structure libraries is that you do not choose data structures by the set of operations which you can perform on them because, for example, all Sequences support the same set of operations. Instead, you pick your data structure by implementation, and live with the fact that some operations are going to be slow on some implementations (e.g. snoc on simple lists is O(n)). Clearly, this is suboptimal. From a programmer's perspective, I shouldn't have to remember the difference between a BinaryRandList and a JoinList. Hence, I have started to implement what I call "facade" types, which wrap underlying implementations to give them names which better reflect what they are used for. Rather than use an Edison.ListSeq, you use an Edison.Stack and use meaningful operations like push and pop rather than cons and tail. I also want to support concurrently accessible data structures, embedded in the IO monad, which will probably be implemented as wrapper functions on top of channels or ports. So now there are three kinds of ways to look at a data structure: - As a concrete implementation - As a facade, exposing those operations that it is optimised for - As a concurrently accessible abstraction The simplest namespace would be something like this: Edison -- Top-level modules may include: Prelude Sequence Collection Association Facade -- Need a better name Stack Queue Deque FiniteMap FiniteTrie Concurrent Stack Queue Deque FiniteMap FiniteTrie Impl Sequence BraunSeq MyersStack Collection SplayHeap BalancedSet BalancedBag Assoc PatriciaLoMap Another option is to dump everything in "Facade" into the top level, but presumably that would require everything in Concurrent to be in the top level too which seems to pollute the top-level namespace a bit too much. Thoughts? Cheers, Andrew Bromage

On Thu, May 29, 2003 at 03:39:11PM +1000, Andrew J Bromage wrote:
As some of you know, I'm hacking up Edison. I'd like some suggestions on namespace issues. Note that at the moment, "Edison" has its own top-level name in the libraries document, and I'm happy for things to stay that way for now.
I'm not sure that the separate top-level name is justified. It will, presumably, be a separate package. I'd prefer to have it under Data, with subhierarchies Data.Association, Data.Collection and Data.Sequence. (Ideally Data.FiniteMap and Data.HashTable would get consistent names too.) That's just for the existing Edison structure.
The main feature of Edison which distinguishes it from other data structure libraries is that you do not choose data structures by the set of operations which you can perform on them because, for example, all Sequences support the same set of operations. Instead, you pick your data structure by implementation, and live with the fact that some operations are going to be slow on some implementations (e.g. snoc on simple lists is O(n)).
Isn't it the other way round -- you write a program using certain operations, and then pick an implementation in which those operations are fast? But things like Data.Queue would also be useful.

G'day all. On Thu, May 29, 2003 at 01:25:10PM +0100, Ross Paterson wrote:
I'm not sure that the separate top-level name is justified.
I'm not so sure about that either, but the hierarchy document had one last time I looked.
Isn't it the other way round -- you write a program using certain operations, and then pick an implementation in which those operations are fast? But things like Data.Queue would also be useful.
The problem is that in general, you don't know in advance precisely which operations you're going to need until you've finished the code which uses them. If you use, say, a stack, you may find part-way through programming that you occasionally need to inspect the second element on the stack, which the stack ADT doesn't naturally support. Rather than force you to change ADTs, Edison just makes the operation available (possibly at some run-time cost, which profiling should tell you about if it's a problem). Sometimes it also makes sense to choose the data structure through operations. Hence the facade modules. Cheers, Andrew Bromage

Dnia czw 29. maja 2003 07:39, Andrew J Bromage napisaĆ:
Facade -- Need a better name
View? -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (3)
-
Andrew J Bromage
-
Marcin 'Qrczak' Kowalczyk
-
Ross Paterson