# Breaking encapsulation in a controlled way using module signatures

**URL:** <https://discourse.haskell.org/t/breaking-encapsulation-in-a-controlled-way-using-module-signatures/2732>\
**Category:** Show and Tell\
**Created:** [July 2, 2021, 9:20pm UTC](https://discourse.haskell.org/t/breaking-encapsulation-in-a-controlled-way-using-module-signatures/2732 "2021-07-02T21:20:49Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![danidiaz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/danidiaz/32/92_2.png) [@danidiaz](https://discourse.haskell.org/u/danidiaz)\
**Post date:** [July 2, 2021, 9:20pm UTC](https://discourse.haskell.org/t/breaking-encapsulation-in-a-controlled-way-using-module-signatures/2732/1 "2021-07-02T21:20:49Z")

</div>

Hi, I wanted to share [this small experiment](https://github.com/danidiaz/really-small-backpack-example/tree/master/lesson11-controlling-encapsulation) about using Backpack module signatures to manage encapsulation “levels” for abstract datatypes.

The basic motivation is the following: we often want abstract datatypes which hide their internals from the prying eyes of other modules. But we also want to be able to inspect the internal structure of values for logging or debugging purposes. How to reconcile the two aims?

In my experiment, the program logic depends on a module signature which defines a `Mystery` type constructor with very few operations. The “inspection” function for datatypes returns `String`s wrapped in this `Mystery` constructor. Other functions in the program logic can’t do anything with these wrapped values.

However, “framework” -like code gives a concrete implementation to the `Mystery` type constructor, meaning that it can can do useful things with the result of “inspection” functions.

I’m left with a question: can something similar to this be achieved without Backpack?

---

<div class="post-metadata">

**Author:** ![jaror](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jaror/32/3271_2.png) [@jaror](https://discourse.haskell.org/u/jaror)\
**Post date:** [July 2, 2021, 9:35pm UTC](https://discourse.haskell.org/t/breaking-encapsulation-in-a-controlled-way-using-module-signatures/2732/2 "2021-07-02T21:35:38Z")

</div>

I think the standard Haskell way to do this is to make a `*.Internal` module which exposes the internals and then the normal module re-exports only the public interface. I have not read your implementation in detail, but it sounds very similar. I assume you are also aware of that, so can you summarize how it is different or why such a `Internal` module is not good enough?

---

<div class="post-metadata">

**Author:** ![danidiaz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/danidiaz/32/92_2.png) [@danidiaz](https://discourse.haskell.org/u/danidiaz)\
**Post date:** [July 3, 2021, 7:01am UTC](https://discourse.haskell.org/t/breaking-encapsulation-in-a-controlled-way-using-module-signatures/2732/3 "2021-07-03T07:01:46Z")

</div>

I wanted to hide the internals of datatypes from other modules _of the same library_, and expose the internals to “framework” code outside the library. The `*.Internal` pattern can help with the second but not with the first: nothing would stop modules from working with the internals of datatypes declared in other modules.

Admittedly, such strong inter-module encapsulation is not very frequent in Haskell.