On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell <[hidden email]> wrote:
> Hi, > > I think reducing breakages is not necessarily, and maybe not even primarily, > an issue of releases. It's more about realizing that the cost of breaking > things (e.g. changing library APIs) has gone up as the Haskell community and > ecosystem has grown. We need to be conscious of that and carefully consider > if making a breaking change (e.g. changing a function instead of adding a > new function) is really necessary. Many platforms (e.g. Java and Python) > rarely, if ever, make breaking changes. If you look at compiler projects > (e.g. LLVM and GCC) you never see intentional breakages, even in major > releases*. Here's a question I think we should be asking ourselves: why is > the major version of base bumped with every release? Is it really necessary > to make breaking changes this often? How about aiming for having GHC 7.10 be > a release where we only add new stuff and improve old stuff? > > -- Johan > > * A major GCC release usually signifies that some large change to the code > generator was made. 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 :-) -- Gaby _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis <[hidden email]> wrote:
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 _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell <[hidden email]> wrote:
> On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis > <[hidden email]> 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 _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Let me strongly support Gaby's many points.
Simon has it right: we need a way to support 'users' in a stable way, without adding enormous inertia to the development of GHC. I has lived through the slow death of a system from being rapidly innovative to having 'innovations' which exist only because a marketer says that the raft of boring, incremental improvements in each new release are innovative on some What's New blurb. Haskell is extremely useful, and GHC's flavour of Haskell is quite exciting because of the continual evolution of the language. Please don't kill the excitement! The Platform does seem to be an ideal mechanism to provide stability for users who value stability over bleeding-edge. But for that to be successful, there are to be strong community commitment [especially from library maintainers] to tracking that evolution. If the social mechanisms are not strong enough to fully support the Platform, I would say that that is the most important thing to fix. Jacques _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Johan Tibell-2
On Mon, Feb 11, 2013 at 7:37 PM, Johan Tibell <[hidden email]> wrote:
gcc has had its moments occasionally, although usually major gcc issues aren't called by gcc itself but by packagers ("gcc 2.96", anyone?) or fugly politics (egcs). brandon s allbery kf8nh sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Simon Peyton Jones
Simon Peyton-Jones <[hidden email]>:
> | > You may ask what use is a GHC release that doesn't cause a wave of updates? > | And hence that doesn't work with at least some libraries. Well, it's a very useful > | forcing function to get new features actually out and tested. > | > | But the way you test new features is to write programs that use them, > | and programs depend on libraries. > > That is of course ideal, but the ideal carries costs. A half way house is a release whose library support will be patchy. Not such good testing, but much lower costs. But still (I think) a lot more testing than "compile HEAD" gives us. I don't think so. In my experience, library support is not patchy, but virtually non-existent as some of the very widely used libraries (like Text) break, and everything else depends on them in one way or another. If we don't make sure that the commonly used libraries work with these "preview" releases, I don't think those releases are worth the effort. I understand that we can't really guarantee API backwards compatibility for the GHC API (but that's ok as few packages depend on that). Critical are all the libraries bundled with GHC. Adding to them is fine, but no API definitions should change or be removed. Manuel _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Johan Tibell-2
On 11/02/13 23:03, Johan Tibell wrote:
> Hi, > > I think reducing breakages is not necessarily, and maybe not even > primarily, an issue of releases. It's more about realizing that the cost > of breaking things (e.g. changing library APIs) has gone up as the > Haskell community and ecosystem has grown. We need to be conscious of > that and carefully consider if making a breaking change (e.g. changing a > function instead of adding a new function) is really necessary. Many > platforms (e.g. Java and Python) rarely, if ever, make breaking changes. > If you look at compiler projects (e.g. LLVM and GCC) you never see > intentional breakages, even in major releases*. Here's a question I > think we should be asking ourselves: why is the major version of base > bumped with every release? Is it really necessary to make breaking > changes this often? 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. Of course we do also make well-intentioned changes to libraries, via the library proposal process, and some of these break APIs. But it wouldn't do any harm to batch these up and defer them until the next API-changing release. It would be great to have a list of the changes that had gone into base in the last few major releases, any volunteers? Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On 02/12/2013 09:37 AM, Simon Marlow wrote:
> On 11/02/13 23:03, Johan Tibell wrote: >> Hi, >> > Of course we do also make well-intentioned changes to libraries, via the > library proposal process, and some of these break APIs. But it wouldn't > do any harm to batch these up and defer them until the next API-changing > release. Indeed. It might even be preferable to just have one "huge" breakage every year than having lots of minor breakages which require updating packages (and dependencies). At least you'll feel you're getting your money's worth. _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Simon Marlow-7
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? -- Live well, ~wren _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
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 [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by wren ng thornton
wren ng thornton <[hidden email]> writes:
[...] > But again, this depends on how feasible it would be to actually split > the packages apart. Is it feasible? Some time last year, I tried to extract the module import inter-dependencies in the base package (with the help of GHC's -ddump-minimal-imports), and came up with the following relations: The main problem I see are the cyclic dependencies between groups of modules; e.g. consider the import-deps between the Prelude module and the GHC.* modules: GHC.ConsoleHandler : Prelude GHC.Constants : Prelude GHC.Environment : Prelude GHC.Event : Prelude GHC.Exts : Prelude GHC.Handle : Prelude GHC.IOBase : Prelude GHC.PArr : Prelude GHC.Stack : Prelude GHC.Stats : Prelude Prelude : GHC.Base Prelude : GHC.Enum Prelude : GHC.Err Prelude : GHC.Float Prelude : GHC.Num Prelude : GHC.Real Prelude : GHC.Show Moreover, the GHC.* modules often also import other standard-library modules such as Data.* for the types and helpers. Also, cyclic dependencies between CABAL packages aren't supported afaik... cheers, hvr _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Simon Marlow-7
* Simon Marlow <[hidden email]> [2013-02-13 09:00:15+0000]
> 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 [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Simon Marlow-7
Perhaps looking at what base-compat has to offer ("A compatibility layer for base") is relevant to this discussion. See: 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 <[hidden email]> wrote:
_______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Roman Cheplyaka-2
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 [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [hidden email] | http://people.debian.org/~nomeata _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Simon Marlow-7
On Wed, Feb 13, 2013 at 09:00:15AM +0000, 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 [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
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: [hidden email] [mailto:[hidden email]] On | Behalf Of Ian Lynagh | Sent: 13 February 2013 13:58 | To: Simon Marlow | Cc: wren ng thornton; glasgow-haskell-users; [hidden email] | Subject: Re: GHC 7.8 release? | | On Wed, Feb 13, 2013 at 09:00:15AM +0000, 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 | [hidden email] | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Roman Cheplyaka-2
Somebody claiming to be Roman Cheplyaka wrote:
>* Simon Marlow <[hidden email]> [2013-02-13 09:00:15+0000] >> 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 _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
In reply to this post by Ian Lynagh-2
Hi,
Am Mittwoch, den 13.02.2013, 13:58 +0000 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 [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [hidden email] | http://people.debian.org/~nomeata _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
> > Am Mittwoch, den 13.02.2013, 13:58 +0000 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 [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
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 +0000 schrieb Ian Lynagh: > On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote: > > Am Mittwoch, den 13.02.2013, 13:58 +0000 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. 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 > * 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 [hidden email] | ICQ# 74513189 | GPG-Keyid: 4743206C JID: [hidden email] | http://people.debian.org/~nomeata _______________________________________________ Glasgow-haskell-users mailing list [hidden email] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |
Free forum by Nabble | Edit this page |