Catch-all considered harmful?

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

Catch-all considered harmful?

Vilem-Benjamin Liepelt-2
Catch-all considered harmful?
=============================
I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts.

Motivation
----------
Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price?

I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.")

I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs.

My questions to the community—

1. Are there real world examples of bugs caused by catch-alls?
2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases?
3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls?

Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence).

Example
-------
Consider the sum type:

    data Answer = No | Yes

and the function:

    foo : Answer -> String
    foo Yes = "Woo-hoo!"
    foo _   = "Bother."

Say we need to extend our sum type:

    data Answer = No | Perhaps | Yes

However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences.

(Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.)


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Catch-all considered harmful?

Vilem-Benjamin Liepelt-2
PS: Some people have already commented on this here: https://gist.github.com/vimuel/ee9b054b42bbc2ed06992a323b7dfbd8

> On 2017-10-03, at 18:59, Vilem-Benjamin Liepelt <[hidden email]> wrote:
>
> Catch-all considered harmful?
> =============================
> I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts.
>
>
> Motivation
> ----------
> Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price?
>
> I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.")
>
> I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs.
>
> My questions to the community—
>
> 1. Are there real world examples of bugs caused by catch-alls?
> 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases?
> 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls?
>
> Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence).
>
>
> Example
> -------
> Consider the sum type:
>
>     data Answer = No | Yes
>
> and the function:
>
>     foo : Answer -> String
>     foo Yes = "Woo-hoo!"
>     foo _   = "Bother."
>
> Say we need to extend our sum type:
>
>     data Answer = No | Perhaps | Yes
>
> However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences.
>
> (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.)
>
>

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Catch-all considered harmful?

Christopher Allen
In reply to this post by Vilem-Benjamin Liepelt-2
We made it a policy at a previous company using Haskell to not use
catch-all patterns whenever possible because it meant adding a new
value to a sum type could mean silent problems. We had one bad
experience with that, did the five-whys thing, never did it again.

This mostly applied to the data types we made to represent domain
specific information. Less true for stuff like `Int`, naturally.

On Tue, Oct 3, 2017 at 12:59 PM, Vilem-Benjamin Liepelt <[hidden email]> wrote:

> Catch-all considered harmful?
>
> =============================
>
> I have been thinking about a potential source of bugs from catch-all pattern
> matches on sum types and would like to know your thoughts.
>
> Motivation
>
> ----------
>
> Totality is usually a desirable property of a function and the catch-all can
> conveniently buy us totality. But at what price?
>
> I have been indoctrinated that rigour goes above convenience (think along
> the lines of: "Once we indulge in the impurities of I/O, there is no
> redemption.")
>
> I would like to evaluate the trade-offs between convenience for the
> programmer and a potential source of bugs.
>
> My questions to the community—
>
> 1. Are there real world examples of bugs caused by catch-alls?
> 2. Do you think that a language extension that disallows catch-alls (and
> annotations to opt back in at pattern match sites or type declaration) could
> be useful for certain code bases?
> 3. If this is a potential problem, then can you think of any better
> solutions a compiler could provide (i.e. that don't rely on an IDE /
> structured editing) other than disallowing catch-alls?
>
> Feel free to chip in with your 2p (or 2¢), but please only if you have any
> concrete experience (or compelling theoretical evidence).
>
> Example
>
> -------
>
> Consider the sum type:
>
>     data Answer = No | Yes
>
> and the function:
>
>     foo : Answer -> String
>     foo Yes = "Woo-hoo!"
>     foo _   = "Bother."
>
> Say we need to extend our sum type:
>
>     data Answer = No | Perhaps | Yes
>
> However, we forget to handle the new case appropriately in `foo`. The
> compiler is happy, but at runtime `foo Perhaps` would evaluate to
> `"Bother."`—with potentially catastrophic consequences.
>
> (Please imagine this happening in a large codebase with several
> contributors, no single one of whom knows the entire codebase.)
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Catch-all considered harmful?

Christopher Allen
In reply to this post by Vilem-Benjamin Liepelt-2
Addendum: it's more a smell when you aren't unconditionally ignoring
an sum type argument - it's when you're special casing _some_ behavior
for specific constructors and then not doing so for others that I
would tend to reject it on code review.

On Tue, Oct 3, 2017 at 1:02 PM, Vilem-Benjamin Liepelt <[hidden email]> wrote:

> PS: Some people have already commented on this here: https://gist.github.com/vimuel/ee9b054b42bbc2ed06992a323b7dfbd8
>
>> On 2017-10-03, at 18:59, Vilem-Benjamin Liepelt <[hidden email]> wrote:
>>
>> Catch-all considered harmful?
>> =============================
>> I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts.
>>
>>
>> Motivation
>> ----------
>> Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price?
>>
>> I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.")
>>
>> I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs.
>>
>> My questions to the community—
>>
>> 1. Are there real world examples of bugs caused by catch-alls?
>> 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases?
>> 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls?
>>
>> Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence).
>>
>>
>> Example
>> -------
>> Consider the sum type:
>>
>>     data Answer = No | Yes
>>
>> and the function:
>>
>>     foo : Answer -> String
>>     foo Yes = "Woo-hoo!"
>>     foo _   = "Bother."
>>
>> Say we need to extend our sum type:
>>
>>     data Answer = No | Perhaps | Yes
>>
>> However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences.
>>
>> (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.)
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



--
Chris Allen
Currently working on http://haskellbook.com
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Catch-all considered harmful?

Li-yao Xia-2
In reply to this post by Vilem-Benjamin Liepelt-2
There was a discussion about that here some time ago:

https://mail.haskell.org/pipermail/haskell-cafe/2017-January/126157.html

Li-yao

On 10/03/2017 01:59 PM, Vilem-Benjamin Liepelt wrote:

> Catch-all considered harmful?
> =============================
>
> I have been thinking about a potential source of bugs from catch-all pattern matches on sum types and would like to know your thoughts.
>
>
> Motivation
> ----------
>
> Totality is usually a desirable property of a function and the catch-all can conveniently buy us totality. But at what price?
>
> I have been indoctrinated that rigour goes above convenience (think along the lines of: "Once we indulge in the impurities of I/O, there is no redemption.")
>
> I would like to evaluate the trade-offs between convenience for the programmer and a potential source of bugs.
>
> My questions to the community—
>
> 1. Are there real world examples of bugs caused by catch-alls?
> 2. Do you think that a language extension that disallows catch-alls (and annotations to opt back in at pattern match sites or type declaration) could be useful for certain code bases?
> 3. If this is a potential problem, then can you think of any better solutions a compiler could provide (i.e. that don't rely on an IDE / structured editing) other than disallowing catch-alls?
>
> Feel free to chip in with your 2p (or 2¢), but please only if you have any concrete experience (or compelling theoretical evidence).
>
>
> Example
> -------
>
> Consider the sum type:
>
>      data Answer = No | Yes
>
> and the function:
>
>      foo : Answer -> String
>      foo Yes = "Woo-hoo!"
>      foo _   = "Bother."
>
> Say we need to extend our sum type:
>
>      data Answer = No | Perhaps | Yes
>
> However, we forget to handle the new case appropriately in `foo`. The compiler is happy, but at runtime `foo Perhaps` would evaluate to `"Bother."`—with potentially catastrophic consequences.
>
> (Please imagine this happening in a large codebase with several contributors, no single one of whom knows the entire codebase.)
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.