Void type in base

older
Workflow for maintaining Haskell...

Shachaf Ben-Kiki

17 Jul 2013 17 Jul '13

1:14 a.m.

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. The proposal is just to copy the Data.Void API into base: data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception (void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.) void could then re-export Data.Void so packages that depend on it will keep working. ("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.) hashable and semigroups would also need to be updated to add their respective instances as non-orphans. The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`. Discussion period: 2 weeks. Shachaf

Show replies by date

Andreas Abel

17 Jul 17 Jul

2:27 a.m.

+1 for adding an empty type. -1 for current proposal. Reason: "void" is another name for the unit type, not for the empty type. We know "void" from C, and there it is analogous to Haskell's "()". Also, in Control.Monad there is void :: Functor f => f a -> f () which casts a computation to return something in the unit type, not in the empty type. "Returning nothing" means giving no information, that is, a member of the *unit* type (in contrast, having a member of the empty type is not having nothing, quite the opposite, it is absolute power; one get everything from it using ex-falso-quod-libet). The type could be called "Empty" instead. "absurd" seems fine. Why having "vacuous"? Is it different from "fmap absurd"? Cheers, Andreas On 17.07.13 7:14 AM, 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.

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception

(void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.)

void could then re-export Data.Void so packages that depend on it will keep working.

("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.)

hashable and semigroups would also need to be updated to add their respective instances as non-orphans.

The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`.

Discussion period: 2 weeks.

Shachaf

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

Edward Kmett

3:14 a.m.

The void package predates the void method, and had to rename its extractor to avoid conflict back at the time it was added. Renaming the type would make migration rather painful for the revdeps of the existing void package and turns the migration story from a conditionally empty package to one that actually involves some pain. http://packdeps.haskellers.com/reverse/void -Edward On Wed, Jul 17, 2013 at 2:27 AM, Andreas Abel wrote:

...

+1 for adding an empty type. -1 for current proposal. Reason:

"void" is another name for the unit type, not for the empty type. We know "void" from C, and there it is analogous to Haskell's "()".

Also, in Control.Monad there is

void :: Functor f => f a -> f ()

which casts a computation to return something in the unit type, not in the empty type.

"Returning nothing" means giving no information, that is, a member of the *unit* type (in contrast, having a member of the empty type is not having nothing, quite the opposite, it is absolute power; one get everything from it using ex-falso-quod-libet).

The type could be called "Empty" instead.

"absurd" seems fine.

Why having "vacuous"? Is it different from "fmap absurd"?

Cheers, Andreas

On 17.07.13 7:14 AM, 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.

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception

(void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.)

void could then re-export Data.Void so packages that depend on it will keep working.

("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.)

hashable and semigroups would also need to be updated to add their respective instances as non-orphans.

The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`.

Discussion period: 2 weeks.

Shachaf

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Dan Burton

12:44 p.m.

+1 this proposal, regardless of bikeshed color. Another possible type name is "Bottom": that which can be used to fill any hole. Other options: None, Absurd, Closed, Uninhabited, CoUnit? Zilch. In our own little world, Void would be fine. But given we live in a C world, we should probably treat the word Void as a synonym for (). -- Dan Burton On Jul 16, 2013 11:28 PM, "Andreas Abel" wrote:

...

+1 for adding an empty type. -1 for current proposal. Reason:

"void" is another name for the unit type, not for the empty type. We know "void" from C, and there it is analogous to Haskell's "()".

Also, in Control.Monad there is

void :: Functor f => f a -> f ()

which casts a computation to return something in the unit type, not in the empty type.

"Returning nothing" means giving no information, that is, a member of the *unit* type (in contrast, having a member of the empty type is not having nothing, quite the opposite, it is absolute power; one get everything from it using ex-falso-quod-libet).

The type could be called "Empty" instead.

"absurd" seems fine.

Why having "vacuous"? Is it different from "fmap absurd"?

Cheers, Andreas

On 17.07.13 7:14 AM, 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.

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception

(void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.)

void could then re-export Data.Void so packages that depend on it will keep working.

("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.)

hashable and semigroups would also need to be updated to add their respective instances as non-orphans.

The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`.

Discussion period: 2 weeks.

Shachaf

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

-- Andreas Abel <>< Du bist der geliebte Mensch.

Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY

andreas.abel@ifi.lmu.de http://www2.tcs.ifi.lmu.de/~**abel/ http://www2.tcs.ifi.lmu.de/~abel/

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Michael Snoyman

2:34 a.m.

I'd recommend including this code in a different module name in base, as that way there won't be any module name conflicts with the existing void package. It will hopefully make it a bit easier to have this transition. On Wednesday, July 17, 2013, 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.

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception

(void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.)

void could then re-export Data.Void so packages that depend on it will keep working.

("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.)

hashable and semigroups would also need to be updated to add their respective instances as non-orphans.

The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`.

Discussion period: 2 weeks.

Shachaf

_______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

3:08 a.m.

If the proposal made it into base more or less as is, then what I could do is release a version of void to coincide with it that was conditionally empty so users of void would feel no change. e.g. my transformers-compat package uses this technique to make it possible to use the extra data types added in transformers-0.3 back under transformers-0.2 (for users who want to span multiple platforms, such as lens). -Edward On Wed, Jul 17, 2013 at 2:34 AM, Michael Snoyman wrote:

...

I'd recommend including this code in a different module name in base, as that way there won't be any module name conflicts with the existing void package. It will hopefully make it a bit easier to have this transition.

On Wednesday, July 17, 2013, 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.

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, Ix, Exception

(void also has a vacuousM for Monad, but since Functor will probably become a superclass, it might not be necessary to export it... By default it probably makes sense to include it, though.)

void could then re-export Data.Void so packages that depend on it will keep working.

("void" also has unsafe functions -- namely unsafeVacuous, which isn't safe with an invalid Functor instance -- but those probably don't belong in base.)

hashable and semigroups would also need to be updated to add their respective instances as non-orphans.

The instances should probably be made compatible with void's. In particular note that void's Eq instance has `_ == _ = True`.

Discussion period: 2 weeks.

Shachaf

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

John Wiegley

3:21 p.m.

+1 for Void and absurd; I'm also unclear as to why vacuous is needed. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

Edward Kmett

3:27 p.m.

vacuous is mostly historical. Back in the day it used to be implemented by an unsafeCoerce at the behest of Conor McBride who didn't want to pay for traversing the whole Functor and replacing its contents, when the types tell us that it shouldn't have any. This is correct if applied to a proper Functor, but subvertible in the presence of GADTs. Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter. -Edward On Wed, Jul 17, 2013 at 3:21 PM, John Wiegley wrote:

...

+1 for Void and absurd; I'm also unclear as to why vacuous is needed.

-- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

David Luposchainsky

3:48 p.m.

On 2013-07-17 21:27, Edward Kmett wrote:

...

vacuous is mostly historical.

Back in the day it used to be implemented by an unsafeCoerce at the behest of Conor McBride who didn't want to pay for traversing the whole Functor and replacing its contents, when the types tell us that it shouldn't have any. This is correct if applied to a proper Functor, but subvertible in the presence of GADTs.

Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter.

+1 in genereal. A few remarks: 1. We don't live in a C world. If you live in France, knowing some English might not hurt, but nobody would say "well they say 'fish' in English so let's call it that as well". That said, I'm neither for nor against "Void", I'd be fine with whatever makes sense in some context, and that C inertia should not be part of that context. 2. I'm not sure we should be concerned about backwards compatibility when introducing a completely new module to Base. If necessary, a compatibility lib on Hackage is enough. David

Joachim Breitner

6:03 p.m.

Hi, Am Mittwoch, den 17.07.2013, 15:27 -0400 schrieb Edward Kmett:

...

Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter.

how would lifting newtype coercions to functors help here: vacuous :: Functor f => f Void -> f a Void is not a newtype of a. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

Edward Kmett

18 Jul 18 Jul

1:33 p.m.

You can get there if you use newtype Void = Void { absurd :: forall a. a } instead. -Edward On Wed, Jul 17, 2013 at 6:03 PM, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, den 17.07.2013, 15:27 -0400 schrieb Edward Kmett:

...
Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter.

how would lifting newtype coercions to functors help here: vacuous :: Functor f => f Void -> f a Void is not a newtype of a.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Dan Doel

8:24 p.m.

Are GHC's newtype coercions going to know that the second step of 'f Void -> f (forall a. a) -> forall a. f a' is valid due to f being a Functor? I'm not sure that can be counted upon. On Thu, Jul 18, 2013 at 1:33 PM, Edward Kmett wrote:

...

You can get there if you use

newtype Void = Void { absurd :: forall a. a }

instead.

-Edward

On Wed, Jul 17, 2013 at 6:03 PM, Joachim Breitner < mail@joachim-breitner.de> wrote:

...
Hi,

Am Mittwoch, den 17.07.2013, 15:27 -0400 schrieb Edward Kmett:

...
Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter.

how would lifting newtype coercions to functors help here: vacuous :: Functor f => f Void -> f a Void is not a newtype of a.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward Kmett

8:36 p.m.

It doesn't sound like the newtype coercions we are likely to get are going to be usable in this way regardless. It was just the historical reason for why I kept vacuous around. =) -Edward On Thu, Jul 18, 2013 at 8:24 PM, Dan Doel wrote:

...

Are GHC's newtype coercions going to know that the second step of 'f Void -> f (forall a. a) -> forall a. f a' is valid due to f being a Functor? I'm not sure that can be counted upon.

On Thu, Jul 18, 2013 at 1:33 PM, Edward Kmett wrote:

...
You can get there if you use

newtype Void = Void { absurd :: forall a. a }

instead.

-Edward

On Wed, Jul 17, 2013 at 6:03 PM, Joachim Breitner < mail@joachim-breitner.de> wrote:

...
Hi,

Am Mittwoch, den 17.07.2013, 15:27 -0400 schrieb Edward Kmett:

...
Now the Data.Void.Unsafe module provides that functionality (as unsafeVacuous) and vacuous itself is provided for compatibility with code that used it, and is left in case we ever get something in Functor that lets us apply newtype coercions directly to the Functor's parameter.

how would lifting newtype coercions to functors help here: vacuous :: Functor f => f Void -> f a Void is not a newtype of a.

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Twan van Laarhoven

6:49 a.m.

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. Twan

Joachim Breitner

7:18 a.m.

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. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata@debian.org

Erik Hesselink

7:42 a.m.

On Thu, Jul 18, 2013 at 1:18 PM, Joachim Breitner 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

David Luposchainsky

13 Aug 13 Aug

4:20 a.m.

Hey Libraries, a couple of weeks ago Shachaf proposed adding Void to Base ("Void type in base", 2013-07-17). The discussion period of 2 weeks is over, and there does not seem to be any further discussion of the topic. I think the responses were generally in favour of `Void` and `absurd`, with somewhat mixed opinions on naming and `vacuous`. Maybe we should take the time to finish this proposal up? A reminder,

...

The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, -- Ix, Exception

I'm not sure about vacuous, it was mentioned that it's only historical (also it's just `fmap absurd` so easily reproducable), which means it would be adding something almost deprecated or redundant to Base (old packages could still import the current void package to get that function if necessary). Anyway, +1 in general, independent of the previous remark. David

Edward Kmett

10:20 a.m.

One argument in favor of vacuous is that I'm currently talking to Richard Eisenberg about how to use the new role machinery to possibly let it be an O(1) operation (at least for derived functors). I would rather not remove it and then re-add it. It becomes a code maintenance nightmare for any of us who have to maintain across multiple versions of GHC then. -Edward On Tue, Aug 13, 2013 at 4:20 AM, David Luposchainsky < dluposchainsky@googlemail.com> wrote:

...

Hey Libraries,

a couple of weeks ago Shachaf proposed adding Void to Base ("Void type in base", 2013-07-17). The discussion period of 2 weeks is over, and there does not seem to be any further discussion of the topic.

I think the responses were generally in favour of `Void` and `absurd`, with somewhat mixed opinions on naming and `vacuous`.

Maybe we should take the time to finish this proposal up? A reminder,

...
The proposal is just to copy the Data.Void API into base:

data Void -- EmptyDataDecls is in Haskell 2010 absurd :: Void -> a vacuous :: Functor f => f Void -> f a -- instances for Typeable, Data, Generic, Eq, Ord, Show, Read, -- Ix, Exception

I'm not sure about vacuous, it was mentioned that it's only historical (also it's just `fmap absurd` so easily reproducable), which means it would be adding something almost deprecated or redundant to Base (old packages could still import the current void package to get that function if necessary).

Anyway, +1 in general, independent of the previous remark.

David

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

4298

Age (days ago)

4325

Last active (days ago)

List overview

Download

17 comments

11 participants

participants (11)

Andreas Abel
Dan Burton
Dan Doel
David Luposchainsky
Edward Kmett
Erik Hesselink
Joachim Breitner
John Wiegley
Michael Snoyman
Shachaf Ben-Kiki
Twan van Laarhoven

Void type in base

John Wiegley

tags

participants (11)