JP Bernardy wrote:
[...] Therefore, I hereby submit it to the people in charge of the hierarchical libraries, for integration. Of course, if any specific detail deserves work, I remain available. [...]
I could add DData to the hierarchical libraries in the fptools repository, but first a few points should be clarified:
Can we hold off on this a while longer please. Partly because I am not here :-) but also I think it needs at least one more round of reviewing, and there is still Ross's overloaded sequences suggestion to decide on. The intention was for the DData libraries to be placed directly under Data (i.e. Data.Set etc.). I had imagined that we would leave the old interfaces available too, deprecated, as long as the names didn't clash. None of this precludes adding overloaded collections later; all we're doing here is adding some concrete data structures. Cheers, Simon
Simon Marlow wrote:
[...] The intention was for the DData libraries to be placed directly under Data (i.e. Data.Set etc.). I had imagined that we would leave the old interfaces available too, deprecated, as long as the names didn't clash.
This would work, as I've already tested. Of course modulo possible clashes with the additional identifiers when those modules are imported as a whole, but I can't see a better migration path.
None of this precludes adding overloaded collections later; all we're doing here is adding some concrete data structures.
I really like to support Simon here: We need better support for some concrete basic data structures in the base package (in plain old Haskell98, of course). Waiting for consensus on *the* Grand Unified Framework (tm) will lead us nowhere, the design space is simply too large. If somebody thinks that he has solved all data structure/algorithm needs of the world, offer this SW as a separate package. Time will tell if people really adopt it, that's Open Source: Don't rely on marketing claims, but on evolution... :-) Cheers, S.
On Wednesday 07 Apr 2004 10:11 am, Sven Panne wrote:
I really like to support Simon here: We need better support for some concrete basic data structures in the base package (in plain old Haskell98, of course). Waiting for consensus on *the* Grand Unified Framework (tm) will lead us nowhere, the design space is simply too large.
Me too, this discussion reminds me of the (now aborted AFAIK) attempt to define the grand unified GUI API :-) What we want (well what I want) as a starting point is some non-toy implementations of basic data structures. There may be many useful higher level and unifying abstractions, but which one (if any) is the "best" only time will tell. In any case, I think they will all benefit if decent implementations of the underlying data structures are available. Regards -- Adrian Hey
participants (3)
-
Adrian Hey -
Simon Marlow -
Sven Panne