Void type in base

[Edward Kmett]

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 <andreas.abel at ifi.lmu.de>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 at 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 at ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~**abel/ <http://www2.tcs.ifi.lmu.de/~abel/>
>
>
> ______________________________**_________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130717/da821874/attachment.htm>