[Haskell-cafe] Ensuring all values of an ADT are explicitly handled OR finding all occurrences of type X in my app

[Alexey Vagarenko]

There is a proposal about that
https://github.com/ghc-proposals/ghc-proposals/pull/43

2017-01-31 10:41 GMT+05:00 Saurabh Nanda <saurabhnanda at gmail.com>:

> Actually in team, one who writes `_` match, is very useful as that
>> prevents breaking code when adding new value...I can't really see any
>> problem here. There is real world use case when member of team don't need
>> to cover all cases therefore `_`.
>>
> I **want** code to break when I add a new value to an ADT. I want the
> programmer to go through all the sites where a pattern match was done on a
> particular ADT and explicitly consider the impact of the new value on these
> sites.
>
> Actual use-case -- we start with the following ADT definition and
> call-sites:
>
> data BookingStatus = Confirmed | Cancelled | Abandoned
>> computeRemainingSeats :: BookingStatus -> (...)
>> computeBilling :: BookingStatus -> (...)
>
>
> Now, assume that within `computeAvailability` only `Confirmed` is
> explicitly matched to result in a reduction of available seats, everything
> else is matched by `_` and results in a no-op. What happens when
> `BookingStatus` evolves to have a new value of  `ManualReview`? We want to
> reduce the number of seats till the manual-review of the booking is
> complete. However, the compiler will not force us to look at this
> particular call-site to evaluate this impact.
>
> Another one: assume that within `computeBilling` only `Confirmed is
> explicitly matched to trigger an invoicing action, others are matched via
> `_` to a no-op. What happens when `BookingStatus` evolves to have a new
> value of `Refunded`, which should trigger a credit-note action? Again, the
> compiler is not going to help us here.
>
> One may reason that this is conflation of concerns; that this should be
> split into **three** ADTs -- one for BookingStatus, one for
> AvailabilityStatus and one for BillingStatus. And pedantically this might
> be right. But all of these learnings evolve over time and one may not make
> the right decisions when writing v1 of the system. Under such
> circumstances, can Haskell still help in helping the programmer ensure
> correctness?
>
> -- Saurabh.
>
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20170131/7d094678/attachment.html>