DData

[Iavor S. Diatchki]

hello,
irrespective of if DData is "the" data structure library (whatever that 
means),
or simply another library, could we avoid adding it to the base package?
it would be much nicer, if the base package was split into more components.

and it would also be nice if i can go and download DData on its own, 
whenever there are bugfixes,
or improvements, without needing to download GHC with it.
i don't see any reason why DData should be part of "base".

as for the hirarchical name, DData.Set etc seems perfectly fine for me
(and please no Data.DData.Set, or Data.Structures.Conrete.DData.Set :-) ),
especially since DData aims to provide concrete implementations.
so when i import DData.Set i know i am getting the set implementation 
from DData ---
seems nice and simple.

bye
iavor




Sven Panne wrote:

> Wolfgang Jeltsch wrote:
>
>> If I remember correctly, DData was intended to be the next-generation 
>> standard set of collection modules.  So, maybe, we should just name 
>> the modules Data.Map, Data.Seq, etc.  I think, it was already said 
>> that this should probably be done.
>
>
> If that's the case, it's fine with me. It should then be in the base 
> package,
> not in a separate one.
>
>> A problem is Data.Set but there may be a solution for this. [...]
>
>
> I've just made a quick test, and it seems that there exists a simple 
> solution
> for this: For a transitional time, Data.Set exports both the old API 
> (and marks
> it as DEPRECATED) and the new API, which is easy because there is no 
> incompatible
> overlap.
>
> Cheers,
>    S.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries