aeson and dlist in HP 2013.4.0.0

[Sean Leather]

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.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131118/8aaa0391/attachment.html>