Re: GHC 7.8 release?
On 13/02/13 07:06, wren ng thornton wrote: On 2/12/13 3:37 AM, Simon Marlow wrote: One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. While it will lead to much wailing and gnashing of teeth in the short term, if it's feasible to break GHC.* off into its own package, then I think we should. The vast majority of base seems quite stable or else is rolling along at a reasonable pace. And yet, every time a new GHC comes out, there's a new wave of fiddling the knobs on cabal files because nothing really changed. On the other hand, GHC.* moves rather quickly. Nevertheless, GHC.* is nice to have around, so we don't want to just hide that churning. The impedance mismatch here suggests that they really should be separate packages. I wonder whether GHC.* should be moved in with ghc-prim, or whether they should remain separate... But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
base package (was: GHC 7.8 release?)
* Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+] It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010. The only obstacle I see is that ghc-base, as you call it, uses some amount of base definitions, and so we have a loop. How hard would it be to break this loop? That is, either make GHC.* modules self-contained, or make base not to depend on GHC.*? Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
Perhaps looking at what base-compat has to offer (*A compatibility layer for base*) is relevant to this discussion. See: https://github.com/sol/base-compat#readme http://hackage.haskell.org/package/base-compat I didn't use it but it looks as promising approach to base API stability. All best, Krzysztof Skrzętnicki On Wed, Feb 13, 2013 at 10:00 AM, Simon Marlow marlo...@gmail.com wrote: On 13/02/13 07:06, wren ng thornton wrote: On 2/12/13 3:37 AM, Simon Marlow wrote: One reason for the major version bumps is that base is a big conglomeration of modules, ranging from those that hardly ever change (Prelude) to those that change frequently (GHC.*). For example, the new IO manager that is about to get merged in will force a major bump of base, because it changes GHC.Event. The unicode support in the IO library was similar: although it only added to the external APIs that most people use, it also changed stuff inside GHC.* that we expose for a few clients. The solution to this would be to split up base further, but of course doing that is itself a major upheaval. However, having done that, it might be more feasible to have non-API-breaking releases. While it will lead to much wailing and gnashing of teeth in the short term, if it's feasible to break GHC.* off into its own package, then I think we should. The vast majority of base seems quite stable or else is rolling along at a reasonable pace. And yet, every time a new GHC comes out, there's a new wave of fiddling the knobs on cabal files because nothing really changed. On the other hand, GHC.* moves rather quickly. Nevertheless, GHC.* is nice to have around, so we don't want to just hide that churning. The impedance mismatch here suggests that they really should be separate packages. I wonder whether GHC.* should be moved in with ghc-prim, or whether they should remain separate... But again, this depends on how feasible it would be to actually split the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon __**_ 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: base package (was: GHC 7.8 release?)
Hi, Am Mittwoch, den 13.02.2013, 11:34 +0200 schrieb Roman Cheplyaka: It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010. while you are considering to split base, please also consider separating IO out. We can expect compiling Haskell to, say JavaScript or other targets that are not processes in the usual sense. For these IO might not make sense. Having something below base that provides the pure stuff (common data structures etc.) would enable libraries to easily say: „My algorithm can be used in normal programs as well as in programs that are compiled to JS“ by not depending on base, but on, say, pure-base. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 7.8 release?
On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote: I believe Ian has done some experiments with splitting base further, so he might have more to add here. There are some sensible chunks that can be pulled out, e.g. Foreign.* can be pulled out into a separate package fairly easily IIRC. Part of the problem is that it's hard to see what's possible without actually doing it, because base is so large, and has so many imports and import loops. IMO by far the easiest way to improve base would be to start off by breaking it up into lots of small packages (some of which will probably be single-module packages, others may contain an entire hierarchy like Foreign.*, and others may contain an odd mixture of modules due to dependency problems). Then we can look at which packages ought to be split up, which ought to be coalesced, and which ought to be moved higher up or lower down the dependency tree, and then look at which module imports are preventing what we want to do and see if there's a way to fix them (either by moving a definition and reversing an import, or by changing an import to import something lower down the dependency tree instead). If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. I imagine the first release would let people use the new base without warnings, a year later new base would give deprecated warnings, and the following year we'd remove it. We could do this process slower, but the sooner packages move off of base, the sooner they benefit from fewer major version bumps. The advantages would be: * the new packages would be easier to maintain than base is * we could more easily make other improvements we'd like to make, e.g. we could move the unix and Win32 packages further down the tree without having to do it in one big leap, and without having to put them below the whole of base * if one module causes a major version bump, then only libraries using that functionality would need to relax their dependencies, rather than every single package * some targets (JS, JVM, .NET, etc) or other implementations might want to do things like IO, concurrency, etc, completely differently. This way they'd just use a different io/concurrency package, rather than having to have a different implementation of parts of base * it would be nice if pure libraries could simply not depend on the io package etc, and thus clearly do no IO The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 7.8 release?
I would like to see base split up, but I am reluctant to invest the effort to do it. I'm not going to do it myself, and Ian's time is so precious on many fronts. My guess is that it'll need someone else to take the lead, with advice from HQ. Simon | -Original Message- | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org] On | Behalf Of Ian Lynagh | Sent: 13 February 2013 13:58 | To: Simon Marlow | Cc: wren ng thornton; glasgow-haskell-users; ghc-d...@haskell.org | Subject: Re: GHC 7.8 release? | | On Wed, Feb 13, 2013 at 09:00:15AM +, Simon Marlow wrote: | | I believe Ian has done some experiments with splitting base further, | so he might have more to add here. | | There are some sensible chunks that can be pulled out, e.g. Foreign.* | can be pulled out into a separate package fairly easily IIRC. | | Part of the problem is that it's hard to see what's possible without | actually doing it, because base is so large, and has so many imports and | import loops. IMO by far the easiest way to improve base would be to | start off by breaking it up into lots of small packages (some of which | will probably be single-module packages, others may contain an entire | hierarchy like Foreign.*, and others may contain an odd mixture of | modules due to dependency problems). | | Then we can look at which packages ought to be split up, which ought to | be coalesced, and which ought to be moved higher up or lower down the | dependency tree, and then look at which module imports are preventing | what we want to do and see if there's a way to fix them (either by | moving a definition and reversing an import, or by changing an import to | import something lower down the dependency tree instead). | | If we go this route, then we would probably want to end up without a | package called 'base', and then to make a new package called 'base' that | just re-exports modules from all the new packages. I imagine the first | release would let people use the new base without warnings, a year later | new base would give deprecated warnings, and the following year we'd | remove it. We could do this process slower, but the sooner packages move | off of base, the sooner they benefit from fewer major version bumps. | | The advantages would be: | * the new packages would be easier to maintain than base is | * we could more easily make other improvements we'd like to make, e.g. |we could move the unix and Win32 packages further down the tree |without having to do it in one big leap, and without having to put |them below the whole of base | * if one module causes a major version bump, then only libraries using |that functionality would need to relax their dependencies, rather than |every single package | * some targets (JS, JVM, .NET, etc) or other implementations might want |to do things like IO, concurrency, etc, completely differently. This |way they'd just use a different io/concurrency package, rather than |having to have a different implementation of parts of base | * it would be nice if pure libraries could simply not depend on the io |package etc, and thus clearly do no IO | | The disadvantage is that, at some point between the first release and | the release that removes base, each package will have to have its | dependencies updated. | | | Thanks | Ian | | | ___ | ghc-devs mailing list | ghc-d...@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (was: GHC 7.8 release?)
Somebody claiming to be Roman Cheplyaka wrote: * Simon Marlow marlo...@gmail.com [2013-02-13 09:00:15+] It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010. +1 -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
base package (Was: GHC 7.8 release?)
Hi, Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh: If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. can you transparently re-export a module from another package? I.e. if base depends on io, IO provides System.IO, is there a way for base to tell ghc to pretend that System.IO is in base, but that there is no conflict if io happens to be un-hidden as well. It seems that something like this would be required to move modules from base to something below it without breaking existing code. Also, if it works that smooth, this would not have to be one big reorganization, but could be done piece by piece. The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. (This is assuming that the reorganizing should not change existing module names. If your plan was to give the modules new names, this problem does not exist, but I’d rather prefer the less intrusive approach.) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh:
If we go this route, then we would probably want to end up without a
package called 'base', and then to make a new package called 'base'
that just re-exports modules from all the new packages.
can you transparently re-export a module from another package? I.e. if
base depends on io, IO provides System.IO, is there a way for base to
tell ghc to pretend that System.IO is in base, but that there is no
conflict if io happens to be un-hidden as well.
No. But there are currently no packages that depend on both base and io,
and anyone adding a dependency on io would remove the base dependency at
the same time.
It seems that something like this would be required to move modules from
base to something below it without breaking existing code.
I don't see why that's necessary. base would end up containing a load of
modules that look something like
{-# LANGUAGE PackageImports #-}
module System.IO (module X) where
import io System.IO as X
Also, if it works that smooth, this would not have to be one big
reorganization, but could be done piece by piece.
It's tricky to do it piece by piece. It's hard to remove individual
sensible pieces in the first place, and it means that you can't
subsequently move modules between packages later without breaking code
depending on the new packages.
The disadvantage is that, at some point between the first release and
the release that removes base, each package will have to have its
dependencies updated.
Why remove base? If it is just a list of dependencies and list of
modules to be re-exported, then keeping it (but advocate that it should
not be used) should not be too much a burden.
* Any package using it doesn't benefit from the reduced version bumps,
so we do actually want packages to move away from it
* Even though base (probably) wouldn't require a lot of work at any one
time, it would require a little work every now and again, and that
adds up to a lot of work
* Any time a module is added to one of the new packages, either we'd
have to spend time adding it to base too, or packages continuing to
use base wouldn't (easily) be able to use that new module.
(This is assuming that the reorganizing should not change existing
module names. If your plan was to give the modules new names, this
problem does not exist, but I’d rather prefer the less intrusive
approach.)
The odd module might be renamed, and there will probably be a handful of
definitions that move from one module to another, but for the most part
I was envisaging that we'd end up with the same modules exporting the
same things.
Thanks
Ian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
Hi, I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Am Mittwoch, den 13.02.2013, 18:09 + schrieb Ian Lynagh: On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote: Am Mittwoch, den 13.02.2013, 13:58 + schrieb Ian Lynagh: If we go this route, then we would probably want to end up without a package called 'base', and then to make a new package called 'base' that just re-exports modules from all the new packages. can you transparently re-export a module from another package? I.e. if base depends on io, IO provides System.IO, is there a way for base to tell ghc to pretend that System.IO is in base, but that there is no conflict if io happens to be un-hidden as well. No. But there are currently no packages that depend on both base and io, and anyone adding a dependency on io would remove the base dependency at the same time. hmm, that reminds me of how haskell98 was handled, and it was slightly annoying when haskell98 and base eventually were made to conflict, and we had to patch some unmaintained packages. Ok, in this case io would be introduced with the intention of being used exclusive from base. So as long as we make sure that the set of modules exported by base is always the union of all modules provided by package that have any module in common with base this would be fine. (Why this condition? Imagine io adding IO.GreatModule without base also providing the module. Then a program that still uses base cannot use IO.GreatModule without fixing the dependencies _now_ (or using package imports everywhere). It would be nice if library authors allowed to do the change whenever convenient.) Also, if it works that smooth, this would not have to be one big reorganization, but could be done piece by piece. It's tricky to do it piece by piece. It's hard to remove individual sensible pieces in the first place, and it means that you can't subsequently move modules between packages later without breaking code depending on the new packages. Agreed. The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. * Any package using it doesn't benefit from the reduced version bumps, so we do actually want packages to move away from it We want them to do so. We should not force them (most surely will...) * Even though base (probably) wouldn't require a lot of work at any one time, it would require a little work every now and again, and that adds up to a lot of work Hopefully it is just updating the set of modules to be exported, sounds like it could be automated, given a list of packages. * Any time a module is added to one of the new packages, either we'd have to spend time adding it to base too, or packages continuing to use base wouldn't (easily) be able to use that new module. Hence we should add them; shouldn’t be too much work. After every larger change to base I am forced to touch old, hardly maintained code that I do not know, to get the packages working in Debian again. Hence my plea for staying compatible as long as feasible. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
Somebody signing messages as Joachim Breitner wrote: I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Looks like a good start! Here's an idea: why not use the `haskell2010` package as one of the groupings? It seems like this sort of reorganisation could help solve the problem we currently have where one cannot using any of the features of `base` along with the `haskell2010` modules. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph signature.asc Description: Digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Wed, Feb 13, 2013 at 4:32 PM, Joachim Breitner m...@joachim-breitner.de wrote: No. But there are currently no packages that depend on both base and io, and anyone adding a dependency on io would remove the base dependency at the same time. hmm, that reminds me of how haskell98 was handled, and it was slightly annoying when haskell98 and base eventually were made to conflict, and we had to patch some unmaintained packages. Ok, in this case io would be introduced with the intention of being used exclusive from base. So as long as we make sure that the set of modules exported by base is always the union of all modules provided by package that have any module in common with base this would be fine. (Why this condition? Imagine io adding IO.GreatModule without base also providing the module. Then a program that still uses base cannot use IO.GreatModule without fixing the dependencies _now_ (or using package imports everywhere). It would be nice if library authors allowed to do the change whenever convenient.) There should also be a condition stating that base should only re-export modules, and that those re-exports need to have the same name on another package. This condition guarantees that the only thing you need to change is the import list, and even this change could be (at least partially) automated via a tool take took all your imports and decided which new packages export them. -- Felipe. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Wed, Feb 13, 2013 at 07:32:06PM +0100, Joachim Breitner wrote: I have started a wikipage with the list of all modules from base, for a first round of shuffling, grouping and brainstorming: http://hackage.haskell.org/trac/ghc/wiki/SplitBase Great, thanks for taking the lead on this! The disadvantage is that, at some point between the first release and the release that removes base, each package will have to have its dependencies updated. Why remove base? If it is just a list of dependencies and list of modules to be re-exported, then keeping it (but advocate that it should not be used) should not be too much a burden. * Any package using it doesn't benefit from the reduced version bumps, so we do actually want packages to move away from it We want them to do so. We should not force them (most surely will...) A lot of packages won't react until something actually breaks. (and I suspect many are unmaintained and unused, and won't react even once it does break). * Even though base (probably) wouldn't require a lot of work at any one time, it would require a little work every now and again, and that adds up to a lot of work Hopefully it is just updating the set of modules to be exported, sounds like it could be automated, given a list of packages. * Any time a module is added to one of the new packages, either we'd have to spend time adding it to base too, or packages continuing to use base wouldn't (easily) be able to use that new module. Hence we should add them; shouldn’t be too much work. I realised that there's actually no reason that the new 'base' package has to come with GHC (even immediately after the break-up); it can just be a package on Hackage (and, if desired, in the Haskell Platform). So it could easily be maintained by someone else, and thus be not much work for you, and 0 work for me :-) Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
