<div dir="ltr">Hi Ivan,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 12:06 PM, Ivan Lazar Miljenovic wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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

<div><br></div><div>Regards,</div><div>Sean</div><div><br></div><div>[1] <a href="https://github.com/spl/dlist/issues/4">https://github.com/spl/dlist/issues/4</a></div></div></div></div>