[Haskell-cafe] Backward compatibility

[Brandon Allbery]

On Fri, May 3, 2013 at 5:30 AM, Adrian May
<adrian.alexander.may at gmail.com>wrote:

> How about this: can you guys give me a detailed example of a justified
> deprecation: one so extremely obviously called for that even I would agree.
> I just want to understand the kind of logic that's applied over these
> things.
>

This might not be possible because your notion of a justified change may
not align with other people's. IIRC the removal of the Show constraint on
Num was driven by type level natural numbers? which matter to the type
hackers but not to someone whose main concern is getting an unmaintained
web interface running. (OTOH it also may not have any effect on said web
server, since it mostly affected people who take the somewhat risky action
of defining their own Num instances; I suspect the exceptions change would
have more impact on web stuff.)

As for the exceptions stuff, that was a multi-step change. Exception
handling was somewhat unprincipled and came in two forms, which used the
same function names but in different ways. There was support for IO
exceptions in the Prelude and conflicting support for general exceptions,
which behaved somewhat differently when handed an IO exception, in
Control.Exception. One key behavior was that you had to handle all
exceptions or none at all; the only way to choose specific exceptions was
to handle all of them, inspect the exception object, and rethrow if it
wasn't one you wanted to handle. And inspecting the exception object to see
what it had in it could be tricky at times, because there wasn't much
guidance with respect to user defined exceptions and some library
exceptions did things slightly differently from the ones in the base.

The exception cleanup made IO exceptions and other exceptions behave
consistently and got rid of the conflicting definitions. This did require
source changes, as anyone relying on the Prelude exceptions had to add an
import of Control.Exception and anyone using old-style exceptions generally
had to add a type annotation to their handler; more ideally, they'd rewrite
their exception code to handle specific exceptions or exception classes
instead of poking at the exception object to determine whether it was one
they cared about or not --- but this was not necessary to get older code
running again, only the added type annotation was necessary.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130503/eccf0c91/attachment.htm>