Void type in base

[Erik Hesselink]

On Thu, Jul 18, 2013 at 1:18 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Donnerstag, den 18.07.2013, 12:49 +0200 schrieb Twan van Laarhoven:
>> On 17/07/13 07:14, Shachaf Ben-Kiki wrote:
>> > It seems strange that there's a canonical unit type -- () -- which is
>> > used extensively, but no canonical type for its dual, the uninhabited
>> > type. The closest we have is in Edward Kmett's void package, but
>> > several people seem to prefer to write it themselves rather than incur
>> > an extra dependency, which is a shame.
>>
>> What is the advantage of having Data.Void in base compared to a separate
>> package? I think the real issue is including the module in the Haskell Platform.
>> It is not as if people don't use other platform libraries like containers.
>
> there is an overhead in finding out the package name a module you want
> to use, putting it in your .cabal file and figuring out the right
> dependency range. Up to the point where it might be easier to just
> implement it yourself.
>
> Also every packages causes additional work to downstream packages
> (distributions, stackage, in-house haskell package management). And it
> reduced the visibility of the code therein.
>
> There is a good reason why we have containers, and not packages "map",
> "graph", "set", "tree" and "sequence".
>
> Especially if the code is very small, has no further dependencies and
> unlikely to undergo a lot of API changes (as it the case with
> Data.Void), there is very little advantage in _not_ having it in a
> package like base.

Still, I thought the overall goal was to reduce the size of base.
Also, this functionality isn't used that often, so it can even be
distracting having it in base (e.g. given the potential confusion
mentioned between Void and ()).

Having it in base also means any maintenance work goes to the
maintainers of base instead of a package maintainer, which is also not
ideal.

Erik