On Thu, May 2, 2013 at 5:30 PM, Ertugrul Söylemez <e...@ertes.de> wrote:

> To express this question in a broader context:  Are you leaving a broken
> tool and replacing it with a new shiny one?

So I read the original post, and it really wasn't clear to me what exact
changes were causing the issues; I don't think I'm alone in thinking the OP
could have been a bit more explicit about the nature of the problem.  Also,
at least Flippa is explicitly unmaintained (according to the first hit
googling "Flippa Haskell"), and I hadn't seen mention of WASH for a year or
more.  And of course, ghc-7.0 was released 2.5 years ago, ghc-7.6 is the
current version, and there's been ample time for incompatibilities to

Despite those issues I'm rather sympathetic to the OP, in part because most
of these "breaking changes" aren't replacing a broken tool.  If the
Functor/Applicative/Monad hierarchy were fixed it would cause a lot of
breakage, and I (like many of us I'm sure) would have to update a lot of
packages, but I wouldn't mind because that would be a clear improvement.
But replacing "import List" with "import Data.List"?  That's not even a
problem.  Consider another breaking change, requiring newtype constructors
be in scope for foreign imports.  This required a lot of code churn,
especially as IIRC the CDouble constructor wasn't exported previously (for
reasons of "abstraction", which I can also rant about), so of course it
wouldn't have been in explicit import lists.  At least this has some
marginal utility if you care about Safe Haskell.

I did a lot of work to get packages compilable with ghc-7.6 and submitted
patches to probably a dozen different repos.  Aside from one exception
(related to the FFI), every breaking change was either related to
namespacing/import issues, or bumping versions in .cabal files (I consider
the whole try/catch mess to be an import issue, although at least in that
case the benefit is more obvious).  Two pragmas existed that duplicate
functionality, one was deprecated in the last release and now the other one
is deprecated while the first has been un-deprecated.  It's just
rearranging deck chairs.  It doesn't feel like a significant improvement,
and it's even harder to bill as one.

I don't think there's anything wrong with moving at a fast pace, nor do I
think backwards compatibility should be maintained in perpetuity.
Unfortunately this leaves a lot of scope for migrations to be handled
poorly, and for unintended consequences of shiny new systems.  IMHO both
have caused issues for Haskell developers and users in the recent and more
distant past.  This is an issue where I think the community should
continually try to improve, and if a user calls out a difficulty we should
at least try to learn from it and not repeat the same mistake.

(Unfortunately I'm not really sure what we can learn from this particular
case, but maybe somebody wiser than me could point the way)
Haskell-Cafe mailing list

Reply via email to