G'day all. Quoting JP Bernardy :

Rencent posts about DData and such make me think... Shouldn't it be integrated in the hierarchical libraries?

Possibly, possibly not. DData is a really good set of data structures. However, it does duplicate some stuff which is already there.

Besides, it looks like Edison has been dropped from GHC.

Daan has expressed some interest in unifying DData and Edison, which isn't a bad idea. Edison has been dropped because: - the version that was there isn't actively supported, - the version that _is_ actively supported isn't ready for "prime time" yet, and - nobody is entirely sure that Edison is quite what people want anyway.

More generally, is there a plan for a unified collections framework in the hierarchical libraries?

No, but I would love some concrete suggestions. Here's my attempt to get the ball rolling... 1. There are a lot of things which are logically collections but existing libraries do not consider as (e.g. PackedString, Array, Graph). In a truly unified library, these would be collections. The downside is that fiddling with commonly used code isn't something which should be undertaken lightly, and you'd better be certain that what you're replacing it with is an improvement. 2. There is a lot of merit in Edison's approach where every data structure supports every operation that is possible, even if it's inefficient. Chris Okasaki did this because he often found himself, say, using a stack ADT (which only supports push, pop, top, isEmpty etc) but occasionally needing to peer at the second or third element from the top of the stack. You don't want to have to change data structures just because of this. The main unintended consequences of this are that a) the interface for a data structure looks overwhelming, and b) the support for choosing an appropriate data structure is quite poor. Why would you choose a LazyPairingHeap over a LeftistHeap anyway? As a programmer, I just want to pick a PriorityQueue and get one with reasonable performance characteristics across the board, only going further if I need it. This has led many people to believe that Edison is too heavyweight. 3. Data types with destructive update semantics (some of them thread-safe, some of them not) are becoming increasingly important. A truly unified approach should take this into account, easing the transition from a data type without destructive update to one with as much as possible, should a programmer find this is needed. The unified approach to Arrays is a good example of how this might work in practice. It seems to me that would make sense to decree that all data structures live in a monad which is naturally its "home". This "home" might be the identity monad for many data structures, and for those cases, a set of additional functions would be provided which don't require the monad to be passed. 4. "Proxy containers" are important. On-disk data structures, in-memory compressed representations and fake containers which compute elements on the fly are all good examples of this. To support these, it should be straightforward (as much as possible) to turn your data structure into a unified-collection-architecture-compliant collection. In addition, algorithms should be data-structure-agnostic if at all possible. [Aside: The C++ STL is often touted as a good example of a data structure library where algorithms are data-structure-agnostic, however, this is only partly true. Pretty much all proxy containers are not STL-compliant. This has led to the odd situation where std::vector<int> is a container but std::vector<bool> is not.] The "left-fold-like combinator", which has received some press lately, seems like a good place to start looking. Cheers, Andrew Bromage

On Wed, Jan 14, 2004 at 10:38:15AM +0100, Daan Leijen wrote:

No one seems to support Edison. However, there is an important difference between Edison and DData: DData provides implementations of specific structures, while Edison tried to provide general collection interfaces *and* implementations. I believe that designing good generic collection interfaces is very hard and may even be impossible to do "right" in current Haskell's. So, I guess we will be stuck with concrete data structures for a while :-)

It might be sensible to do the generic thing for sequences only: * the generic interface is fairly clear (PreludeList + List + toList, fromList, empty, cons, snoc, lview, rview and a few others -- the only question is whether to reuse the standard names). * the interface fits in Haskell 98, because element types are unconstrained. * no implementation suits all purposes, and you often want to delay the choice.

...

No one seems to support Edison.

Not entirely true. I support Edison, but I haven't recently because nobody has wanted support. Somewhat circular reasoning, but there you go.

Whoops, sorry for implying this, and thanks for keeping Edison alive. (I wouldn't be too negative about "nobody has wanted support", as projects like edison might suddenly regain new interest. Furthermore, a lot can be learned from how the interfaces have been set up.) Is there somewhere a place where edison resides (fptools cvs?) -- Daan.

Cheers, Andrew Bromage _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

...

Is there somewhere a place where edison resides (fptools cvs?)

The latest version lives here: http://sourceforge.net/projects/hfl

Great. and nice that it is in cvs. Thanks, Daan. (ps. I am going to snowboard for a week so I won't send any ideas/comments any more)

I've deliberately kept it out of fptools while it was in a state of high flux. Nothing worse than people depending on unstable interfaces.

I'd be very happy to put in the work of turning Edison into something else, if that something else is something that this mailing list can generally agree on (or at least live with).

Cheers, Andrew Bromage _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Wolfgang Jeltsch writes:

Am Mittwoch, 14. Januar 2004 22:44 schrieb Derek Elkins:

...

On Windows platforms (at least 2k, almost certainly earlier ones as well though) aux (or aux.* in general) is a special file name.

And XP.

Unbelievable!

Quite. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

On Thu, 2004-01-15 at 01:32, Keith Wansbrough wrote:

...

Don't name the intermediate directories (subheirarchies) or modules Aux. On Windows platforms (at least 2k, almost certainly earlier ones as well though) aux (or aux.* in general) is a special file name.

Certainly since MSDOS 2.0, possibly even 1.0.

IIRC, the reserved names include aux:, con:, prn:, com1:, com2:, com3:, com4:, lpt1:, lpt2:, lpt3:, and nul:. The syntax with the trailing colon is official, but not necessary. So don't name anything with these names :-(

A little testing reveals that (under Windows 2000) the bad list includes at least com1 through com9 and lpt1 through lpt9 (and, as Derek (I think) mentions above, if X is bad, then so is X.*; so Con.lhs is bad). In case people haven't figured it out by the file names, these are the Windows equivalent of Unix character special files. "nul:" is very similar to the Unix "/dev/null"; except that instead of being stuffed away in /dev, Windows pretends there's a copy in every directory (so instead of using "/dev/null", you could use "nul:", or ".\nul", or "..\nul.asdffdsa", or "c:\Nul.hs"; all are equivalent). Carl Witty

Carl Witty writes:

In case people haven't figured it out by the file names, these are the Windows equivalent of Unix character special files. "nul:" is very similar to the Unix "/dev/null"; except that instead of being stuffed away in /dev, Windows pretends there's a copy in every directory (so instead of using "/dev/null", you could use "nul:", or ".\nul", or "..\nul.asdffdsa", or "c:\Nul.hs"; all are equivalent).

Aha, this suggests that it was in MSDOS 1.0 - the "every directory" semantics would have been given in MSDOS 2.0 for backwards compatibility, since pre-2.0 there were no directories. Ouch. We're talking something like 23 years here, at least... :-( --KW 8-)