GHC 7.8 release?

[Gabriel Dos Reis]

On Mon, Feb 11, 2013 at 2:46 AM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> one remedy to the problem could be better infrastructure:
>       * More automated test-building of packages on hackage (including
>         test suites) with various GHC releases, and better display of
>         the results. This way, library authors would not have to
>         manually build their library to see if they work with the latest
>         compiler.
>       * Automatic test building of packages with explicit relaxation of
>         the dependencies, to suggest dependency relaxation that would
>         work without code changes (from my work at Debian, in most cases
>         only meta-data changes are required to support newer versions of
>         dependencies, including core libs).
>       * A more liberal attitude to changing other peoples packages’s
>         metadata to fix the dependencies – either to exclude broken
>         combinations or to expand the range. Preferably online, similar
>         to the edit button in github, and checked by the above CI
>         infrastructure.
>
> This way, it would be easier for libraries to support newer GHC releases
> without having to give up supporting older releases.
>
> But I know that development of Hackage is not something that seems to be
> happening a lot right now, and as I don’t help, I’m not complaining. So
> consider this a side notice and carry on discussing :-)
>
> Greetings,
> Joachim

The issue is largely "social" problem that I suspect technological
solutions won't solve.  Yes, it would be nice to have better
infrastructure.  However, at the end of the day, when the automated
tests say an API or ABI set has been broken, a non-technical
decision needs to be taken (should it be part of the next release, or
should it be delayed or removed?)  And you will be back to square one.

Part of the problem is what happens to successful
programming languages: you get users, and users -- believe it or not --
like stability (few people like fiddling with function names and
arguments in an otherwise working program or library) and, yes they
will take new improvements as long as their working programs continue
working.  Researchers on the other hand need room to experiment with
ideas; they need to get their implementations in the wild to get a sense
of what scales, what doesn't.  These facts are in tension; you can't
solve it by more automated testing.

If you want GHC to compete with GCC or Clang, then you know what
to do: stop experimenting with the language.   So far, most of the work
on GHC has been done by researchers who are not paid to
do "development work" -- unless academia changes its standards...

-- Gaby