aeson and dlist in HP 2013.4.0.0

Sean Leather sean.leather at gmail.com
Mon Nov 18 15:37:26 UTC 2013


Hi Ivan,

On Mon, Nov 18, 2013 at 12:06 PM, Ivan Lazar Miljenovic wrote:

> On 18 November 2013 19:04, Sean Leather wrote:
> > * Deprecate `DL`, `unDL` and add `apply`
>
> The only possible issue I can think of with this from my own
> experience in dealing with my own code with abstract data types with
> no exposed constructors: it made some debugging issues difficult to
> diagnose because the equivalent of fromList and toList led to some
> subtle behaviours.  As such, what about having an .Internals module
> that exposes these?
>

I think the type DList should be abstract. Sometimes, there are occasions
in which it is useful to have access to constructors. 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. My guess is that the most
likely reason for using the constructor is to bypass `fromList`, but this
is much more likely to lead to unexpected values [1] than anything useful
(or optimized).

Regards,
Sean

[1] https://github.com/spl/dlist/issues/4
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131118/01c641a5/attachment.html>


More information about the Libraries mailing list