<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"><br></div><div dir="auto">David</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 Jan 2017 06:48, "Saurabh Nanda" <<a href="mailto:saurabhnanda@gmail.com">saurabhnanda@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Btw, what about the other approach -- listing all possible occurrences of type X throughout the app?<div><br></div><div>-- Saurabh.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 31, 2017 at 12:15 PM, Saurabh Nanda <span dir="ltr"><<a href="mailto:saurabhnanda@gmail.com" target="_blank">saurabhnanda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We want this at my company too, so we don't write fall-through cases.<br></blockquote><div><br></div></span><div>That's a short-term workaround, yes. However it doesn't fit into Haskell's overall story of language-enforced correctness.</div><span class="m_-4214505901436060031HOEnZb"><font color="#888888"><div><br></div><div>-- Saurabh.</div></font></span></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-4214505901436060031gmail_signature" data-smartmail="gmail_signature"><a href="http://www.saurabhnanda.com" target="_blank">http://www.saurabhnanda.com</a></div>
</div>
<br>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/haskell-<wbr>cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div></div>