Derived Functor instance for void types

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

This way if you map over a structure with errors at the leaves you get a
new structure with those same errors at the leaves.

*tl;dr* +1 from me.

-Edward

On Sun, Jan 15, 2017 at 11:00 PM, Kevin Cotrone <kevincotrone at gmail.com>
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 inhabitants.
>
> On Sun, Jan 15, 2017 at 2:37 PM, David Feuer <david.feuer at gmail.com>
> wrote:
>
>> 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
>> snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should
>> double check that no one is opposed.
>>
>> David Feuer
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20170116/0964646c/attachment-0001.html>