+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
+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/
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries