On Mon, Nov 18, 2013 at 6:21 PM, Niklas Hambüchen wrote:
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.
The points are contradictory, but my message was not. I accept that there are reasons to expose constructors, but in this case, I think (1) the reason to hide the DList constructor is strong and (2) the reasons to expose the constructor are weak. Of course, this is somewhat subjective, but I have given evidence why the constructor should be hidden, and I have not seen any non-speculative evidence why it should be exposed.
From my experience, whatever it is, in the end somebody wants to give an instance to it.
In case you haven't seen the code [1], none of the included instances need the constructor. And, since dlists are easily (and, as I argued earlier, probably efficiently) converted to/from lists, those supposed instances that somebody wants to give can be implemented in the same way. Access to the constructor does not help there. I would therefore vote to expose internals of *all* data types exposed.
Not doing so is assuming the ability to foretell everything a user will ever do with it, which is never true.
Actually, I do want to prevent one thing that a user will do with the library: construct a `DList` from an arbitrary `[a] -> [a]` function. That's the point, and the library user loses little and gains a strong assurance of safety. I think I have said enough for this thread. If anyone can come up with a concrete (and safe) example of using the DList constructor outside the library, I would consider that as evidence for exposing it. It's exposed in v0.5 and will be deprecated in v0.6, so there's plenty of time to try. It's always possible to change the code later, too. As I said before [2], I think dlist is perfectly suitable for the Platform, but since it has so far been considered (1) only as a minor dependency to aeson (the formally proposed addition) and (2) somewhat controversial, the aeson proposal might be better simplified to aeson-without-dlist. Regardless of the final choice, however, I'm happy to develop and maintain dlist. Regards, Sean [1] https://github.com/spl/dlist/blob/master/Data/DList.hs [2] http://projects.haskell.org/pipermail/haskell-platform/2013-November/002750....