Am 18.11.2013 17:21, schrieb Niklas Hambüchen:
On 18/11/13 15:37, Sean Leather wrote:
Examples include debugging (yours), implementing functions not included in the library (e.g. this comes up sometimes with Data.Map/Data.Set), and optimization.
...
In the case of DList, the underlying type is so simple that exposing it does not add enough value to warrant a second module.
These two points you give seem very contradicting.
From my experience, whatever it is, in the end somebody wants to give an instance to it.
I would therefore vote to expose internals of *all* data types exposed.
You do not believe in abstract data types, do you? With the constructor exposed you can spoil invariants, i.e. for DList: wrongEmptyList = DL $ const [] toList $ append wrongEmptyList $ fromList [1] yields "[]". Cheers Christian
Not doing so is assuming the ability to foretell everything a user will ever do with it, which is never true. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries