Derived Functor instance for void types

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Derived Functor instance for void types

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 snozzcumbers!" I've opened Trac #13117 to fix this, but I figured I should double check that no one is opposed.

David Feuer

_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Derived Functor instance for void types

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 <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: Derived Functor instance for void types

Edward Kmett-2
In reply to this post by David Feuer
"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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries



_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users