
I've done exactly this a number of times. The approach I generally take is
to define a completely new ADT, mark the old one as deprecated, and then
simply plough through the compiler warnings and errors, which is a mostly
mechanical process.
On occasion I've written a (temporary) injection from the old datatype into
the new one which lets you make the changes piecemeal (by topologically
sorting the usages) which is nice as if there's any risk of making a
mistake then tools like `git bisect` can help you find the slip in the sea
of otherwise identical changes. Doesn't always work smoothly but it's often
ok.
This also has the advantage that you don't have to fix all the usages in
third-party code or dependent libraries straight away. The deprecation step
need not be immediate, depending on how stable your API is supposed to be.
Cheers,
David
On 31 Jan 2017 06:48, "Saurabh Nanda"
Btw, what about the other approach -- listing all possible occurrences of type X throughout the app?
-- Saurabh.
On Tue, Jan 31, 2017 at 12:15 PM, Saurabh Nanda
wrote: We want this at my company too, so we don't write fall-through cases.
That's a short-term workaround, yes. However it doesn't fit into Haskell's overall story of language-enforced correctness.
-- Saurabh.
-- http://www.saurabhnanda.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.