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

[Christopher Allen]

We want this at my company too, so we don't write fall-through cases.

On Mon, Jan 30, 2017 at 11:41 PM, Saurabh Nanda <saurabhnanda at gmail.com> wrote:
>> 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.



-- 
Chris Allen
Currently working on http://haskellbook.com