GHC 7.8 release?

[Gabriel Dos Reis]

On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
> On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>>
>> I have some experience with GCC releases -- having served as a GCC
>> Release Manager for several years. In fact, the release scheme we
>> currently
>> have has gone through several iterations -- usually after many
>> "existential"
>> crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
>> a research compiler and most "research works" are done on forgotten
>> branches
>> that nobody cares about anymore.  Implementing new standards (e.g. moving
>> from C++03 to C++11 that has several mandated API and ABI breakage) is a
>> royal pain that isn't worth replicating in GHC -- at least if you want
>> GHC to remain a research compiler.
>>
>> Concerning your question about release number, I would venture that there
>> is a certain "marketing" aspect to it.  I can tell you that we, the
>> GCC community,
>> are very poor at that -- otherwise, we would have been at version 26
>> or something :-)
>
>
> Thanks for sharing! My perspective is of course as a user. I don't think
> I've ever run into a case where the compiler broken a previous work e.g. C++
> program. On the other hand I have to make a release of most of the libraries
> I maintain with every GHC release (to bump cabal version constraints to
> accept the new base version, if nothing else).
>
> -- Johan
>

I understand.

Concerning GCC, it is true that the shear size of the user base and the
audience of the compiler ("industrial strength") calls for a very conservative
approach to ABI or API breaking.  On the hand, that means that there are
certain welcomed, beneficial changes that we cannot effect.  For
example, because
libstdc++ has been an early adopter of a reference counted-based implementation
of std::string, we could not switch to more efficient and more
multithread-friendly
implementation.  That was has been contributed for years but has been
sequestered
in some branches and namespaces integrated with the rest of the
library.  That is
a shame, but one that is unavoidable given the expectation of the GCC audience.

It is not clear to me that GHC is ready for that kind of constraints.

We are still describing the C++11 implementation as "experimental"
because we "fear"
that doing otherwise might commit ourselves to an ABI and API that we
may need to
break later -- possibly because of undetected bugs or because we have found
implementations we like better.  Of course, that causes some distress
in the community
because people would like to say "GCC implements C++11."

Finally, we do break API, you have just been lucky :-)

     http://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html

But, we have also developed very elaborate scheme for symbol
versioning and namespace associations to help users digest API breakages
without tears.  Symbol versioning is a very messy business.

I am still of the opinion that the current issue with GHC and HP is
social, and it
can be resolved through communication and coordination between the two
communities for the great good of the Haskell community.

-- Gaby