Re: Derived Functor instance for void types

2017-01-15 Thread Edward Kmett
"Preserving user bottoms" was found to be better behavior for us with Void as well back in the day. Evaluating such a term to get the bottom out is better than making up one that loses information for the user about precisely what bottom it is they had. We do so with absurd and the like for Void.

Re: Derived Functor instance for void types

2017-01-15 Thread David Feuer
I don't know what you mean. fmap for an uninhabited type is vacuously strict: its result is always _|_. On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone wrote: > That seems to have a surprising strictness. > > I'm not sure if it would be the best idea to try and evaluate a type with no > inhabitan

Derived Functor instance for void types

2017-01-15 Thread David Feuer
Currently, if you write data V a deriving Functor GHC generates fmap _ _ = error "Void fmap" This seems quite unfortunate, because it loses potentially useful error information: fmap (+ 3) (error "Too many snozzcumbers!") throws "Void fmap", rather than the much more precise "Too many snozzcu