No subject
Mon May 13 21:54:11 BST 2013
> 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
--bcaec520f3cb176c5b04eb78ec1c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Nov 18, 2013 at 6:21 PM, Niklas Hamb=C3=BCchen=C2=A0wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex">
<div>On 18/11/13 15:37, Sean Leather wrote:<br>
> Examples<br>
> include debugging (yours), implementing functions not included in the<=
br>
> library (e.g. this comes up sometimes with Data.Map/Data.Set), and<br>
> optimization.<br>
<br>
</div>...<br>
<div><br>
> In the case of DList, the underlying type is so simple<br>
> that exposing it does not add enough value to warrant a second module.=
<br>
<br>
</div>These two points you give seem very contradicting.<br></blockquote><d=
iv><br></div><div>The points are contradictory, but my message was not. I a=
ccept that there are reasons to expose constructors, but in this case, I th=
ink (1) the reason to hide the DList constructor is strong and (2) the reas=
ons to expose the constructor are weak. Of course, this is somewhat subject=
ive, 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.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">From my experience, whatever it is, in the =
end somebody wants to give an<br>
instance to it.<br></blockquote><div><br></div><div>In case you haven't=
seen the code [1], none of the included instances need the constructor. An=
d, since dlists are easily (and, as I argued earlier, probably efficiently)=
converted to/from lists, those supposed instances that somebody wants to g=
ive can be implemented in the same way. Access to the constructor does not =
help there.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">I would therefore vote to expose internals =
of *all* data types exposed.<br>
Not doing so is assuming the ability to foretell everything a user will<br>
ever do with it, which is never true.<br>
</blockquote></div></div><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">Actually, I do want to prevent one thing that a user will do =
with the library: construct a `DList` from an arbitrary `[a] -> [a]` fun=
ction. That's the point, and the library user loses little and gains a =
strong assurance of safety.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I think I h=
ave 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 wil=
l be deprecated in v0.6, so there's plenty of time to try. It's alw=
ays possible to change the code later, too.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">As I said b=
efore [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 propo=
sal might be better simplified to aeson-without-dlist. Regardless of the fi=
nal choice, however, I'm happy to develop and maintain dlist.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Regards,<br=
>
</div><div class=3D"gmail_extra">Sean</div><div class=3D"gmail_extra"><br><=
/div><div class=3D"gmail_extra">[1]=C2=A0<a href=3D"https://github.com/spl/=
dlist/blob/master/Data/DList.hs">https://github.com/spl/dlist/blob/master/D=
ata/DList.hs</a></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">[2] <a href=
=3D"http://projects.haskell.org/pipermail/haskell-platform/2013-November/00=
2750.html">http://projects.haskell.org/pipermail/haskell-platform/2013-Nove=
mber/002750.html</a><br>
</div></div>
--bcaec520f3cb176c5b04eb78ec1c--
More information about the Haskell-platform
mailing list