On Friday 17 June 2011, 17:11:39, Jacques Carette wrote:

I favour Plan A.

+1

On Fri, Jun 17, 2011 at 11:11, Jacques Carette wrote:

they chose to stick to pure Haskell 98.  Plan B is actually more fragile in that respect, in that if they forget to be really really explicit about their code being pure Haskell 98, the resulting compilation errors do not make it obvious that that is actually the problem.  This will in fact only get worse as time goes by.

This is a very good point that is glossed over by the proposal: is Haskell 98 the default or is the current Haskell standard the default, and how do we handle existing code bases that might be broken by incompatible changes (the point of this discussion)? It's really the same question seen from a higher level. -- brandon s allbery                                      allbery.b@gmail.com wandering unix systems administrator (available)     (412) 475-9364 vm/sms

Simon Peyton-Jones, if you say: "Under Plan A, some Hackage packages will become un-compilable, and will require source code changes to fix them. I do not have any idea how many Hackage packages would fail in this way." If you don't have any idea "how many Hackage packages would fail this way" then it doesn't make sense to this Noob to go Plan A. I would prefer everything is "explicit" rather than some "implicit" and some "explicit". It will be very frustrating to debug in such case (implicit/explicit). Thank you. Simon. 2011/6/17 Jacques Carette

On 17/06/2011 10:47 AM, Simon Peyton-Jones wrote:

...

But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story.

I favour Plan A.

Reasoning: For many years of my previous professional life, I had to live with extreme backwards compatibility in the code base. This introduced a huge amount of inertia, to the point where past design mistakes became entrenched as 'features'. Forward progress became glacial. Very bad.

Your plan A on the other hand strikes a really good balance: the only libraries affected are those which mix H98 and more modern modules. This means that the authors are already beyond Haskell 98, and realize that there is real value to go beyond that. So they should be reasonably amenable to continue to move forward.

On the other hand, those who were very careful to stick to pure Haskell 98 (for whatever reason), have a very clear path for their code to continue to stay functional. They get all the backwards compatibility they desired when they chose to stick to pure Haskell 98. Plan B is actually more fragile in that respect, in that if they forget to be really really explicit about their code being pure Haskell 98, the resulting compilation errors do not make it obvious that that is actually the problem. This will in fact only get worse as time goes by.

Jacques

______________________________**_________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.**org http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users

On 18/06/2011 11:20, Malcolm Wallace wrote:

As one of the few people who has habitually used Haskell'98 wherever possible, I favour plan A. As I recently discovered, in ghc 7 it is already very fragile to attempt to depend on both the base and haskell98 packages simultaneously. In most cases it simply doesn't work. Removing those few remaining cases where it happens to work by accident would be a good move.

This is a good point - as the APIs in base diverge more and more from those in haskell98, the illusion that you can use both at the same time becomes harder to maintain. For example, the Random class from System.Random is now different from the one in haskell98's Random, so mixing the two doesn't work. While the breakage of existing code is definitely regrettable, I'm slightly in favour of plan A. In most cases the fixes will be a simple renaming of imports (we could probably make a script to do this, even). Also plan A matches what we do for haskell2010, where we really have no choice because all the modules overlap with base. Cheers, Simon