Re: GHC and Haskell 98
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 17/06/2011 16:42, Brandon Allbery wrote: On Fri, Jun 17, 2011 at 11:11, Jacques Carettecare...@mcmaster.ca 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. When you're using Cabal, there's no default, because all package dependencies are specified explicitly. When using standalone GHCi or ghc the plan A default would be - LANGUAGE Haskell2010 - -package base whereas currently (GHC 7.0) it is - LANGUAGE Haskell2010 - -package base -package haskell98 which is already a bit weird. We could make it - LANGUAGE Haskell2010 - -package haskell2010 but that would confuse a lot of people for negligible gain. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
From: Bas van Dijk v.dijk@gmail.com 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). Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? I suspect it's not needed for the majority of cases. +1 for Plan A, but interested in mitigating the negative consequences. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) John Lato ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On Mon, Jun 20, 2011 at 10:54:30AM +0100, John Lato wrote: From: Bas van Dijk v.dijk@gmail.com 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). Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? I suspect it's not needed for the majority of cases. +1 for Plan A, but interested in mitigating the negative consequences. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) John Lato This thread seems to focus way too much on Hackage alone. What about all the existing codebases out there, in production? -- Lars Viklund | z...@acc.umu.se ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 20 June 2011 11:54, John Lato jwl...@gmail.com wrote: Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? You could write a script that will download them all, remove the haskell98 dep. and cabal build the package. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) It seems my dyndns account is removed! You can still access our server via its IP number: http://81.26.216.99/~roel/hackage/packages/hackage.html Regards, Bas ___ 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 Peyton-Jones writes: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. So Plan A also involves hiding the haskell98 package by default? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On Mon, Jun 20, 2011 at 12:43:37PM +0100, Paterson, Ross wrote: Simon Peyton-Jones writes: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. So Plan A also involves hiding the haskell98 package by default? Yes. This puts it in the same category as haskell2010, which is already hidden by default in GHC 7.0. Also, note that hiding makes no difference when using Cabal. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
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 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
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
GHC and Haskell 98
Friends, this is to ask your opinion about a possible change in GHC 7.2. The
current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for
us, but I think it may be a bit draconian, and therefore propose Plan B as an
alternative. Opinions?
Simon
==
With GHC 7.0 if you say
ghc -c Main.hs
the import of Prelude, whether implicit or explicit, will come from package
'base'. This is also true if you say
ghc -c Main.hs -package haskell98
The package 'haskell98' exposes 'List' and 'Random' but not 'Prelude'. That
still comes from 'base'.
This isn't good, because it means that if in the future we change 'Prelude' in
package 'base', a Haskell98 module might fail to compile. And later iterations
of Haskell might well want to expand or change the Prelude.
There appear to be two alternatives:
(Plan A) Add a module 'Prelude' to package 'haskell98'.
Now you can compile a pure H98 program thus:
ghc -c Main.hs -hide-all-packages -package haskell98
(Cabal puts the -hide-all-packages in for you.) And this will
continue to work even if later iterations of Haskell change the
Prelude.
BUT (A) means that this module becomes un-compilable:
module Main where
import Random
import Data.List
Why? Because 'Random' comes from 'haskell98' and 'Data.List' comes from
'base'. But if you say
ghc -c Main.hs -package base -package haskell98
then the (implicit) import of 'Prelude' will say Ambiguous module name:
Prelude, because it's exported by both 'base' and 'haskell98'. To fix this
you have to change 'import Random' to 'import System.Random'. But the latter's
API is different, so you may have to change the source code that uses it.
So the second alternative is this:
(Plan B) Like Plan A, but in addition, if you say {-# LANGUAGE Haskell98 #-}
in the file, or -XHaskell98 on the command line, the implicit import
of Prelude comes from package 'haskell98', provided -package
haskell98
is specified, but regardless of what other in-scope packages expose
a Prelude module.
Variation: an explicit 'import Prelude' is similarly directed to
package 'haskell98' as well.
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.
Unser Plan B, Hackage package that compile now will continue
to compile, if their Cabal file is altered. No source code changes.
(Well, unless they depend on some innards of GHC.IO or
something like that.)
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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
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-users
Re: GHC and Haskell 98
On Friday 17 June 2011, 17:11:39, Jacques Carette wrote: I favour Plan A. +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On Fri, Jun 17, 2011 at 11:11, Jacques Carette care...@mcmaster.ca 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 allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC and Haskell 98
On 6/17/11, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Friday 17 June 2011, 17:11:39, Jacques Carette wrote: I favour Plan A. +1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users +2 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
