|
|
12345678
|
|
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:
I have some experience with GCC releases -- having served as a GCC
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 _______________________________________________
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.htmlBut, 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
|
|
|
On Mon, Feb 11, 2013 at 7:37 PM, Johan Tibell <[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).
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
* 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
|
|
|
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
_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
|
|
|
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
|
|
|
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
|
|
|
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
|
|
|
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/SplitBaseAm 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.
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
[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
|
12345678
|
Locked
all-deps.lst (48K)