aeson and dlist in HP 2013.4.0.0

Gregory Collins greg at
Mon Nov 18 17:14:17 UTC 2013

On Mon, Nov 18, 2013 at 5:40 PM, Peter Simons <simons at> wrote:

> ...but I never had any trouble because
> a library exposed a type that I didn't need access to.

I've definitely had the experience of pattern matching on somebody's
constructor and then having my code break when a new record field was
added. The convention I use, and which I have seen others use, is that
datatypes are exported abstractly in "public" APIs but are also
(optionally) exported from an ".Internal" module. The "contract" you give
to API users about what kinds of changes should be breaking can then be a
little stronger in the public API. Consumers of modules marked "internal"
deserve what they get :)

Other concrete examples where this has helped me as a library author in the
past: In the snap-core web programming package, I have redefined the "Snap"
monad half a dozen times but consumers of the public library API have to my
recollection never been affected by these changes. This would not be
possible without the datatype abstraction.

As others have posted, keeping datatypes abstract also lets you maintain
invariants that unfettered access to the datatype constructors might allow
you to violate. For dozens of reasons it's a software engineering "best

Gregory Collins <greg at>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list