Void type in base

[Dan Burton]

+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" <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/cb1264cf/attachment.htm>