Re: GHC and Haskell 98

[Malcolm Wallace]

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.

Regards,
Malcolm

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC and Haskell 98

[Simon Sin]

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 care...@mcmaster.ca

 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 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-usershttp://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC and Haskell 98

[Bas van Dijk]

On 17 June 2011 16:47, Simon Peyton-Jones simo...@microsoft.com wrote:
 So:    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.

Of the 372 direct reverse dependencies of haskell98:

http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskell98-1.1.0.1#direct

there are 344 which also depend on base (See http://hpaste.org/47933
for calculating the intersection).

Am I correct that a package which depends on both base and haskell98
will always fail to build when the Prelude is also exported from
haskell98? (Unless of course the package uses the PackageImports
extension)

I don't know how many of these 344 packages use PackageImports or have
upper bounds on their haskell98 dependency (I guess not many). So I
guess many of these 344 will break.

Still I'm in favour of plan A since it's simple and discourages mixing
haskell98 with more modern modules.

Regards,

Bas

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users