Re[2]: Adding System.FilePath
Hello Artem, Friday, March 16, 2007, 12:09:49 PM, you wrote:
Unlike a lot of other languages (like Java) which grow incrementally, heaving the whole lot of old baggage in their library API, GHC base is allowed to evolve its interfaces (and yes, that breaks compatibility). I think it is a healthy approach, while the Java approach might bloat it to death (sadly, as i'm a Java user; at least the bytecode seem remains in good shape). Sorry if it seem like offtopic, but i think the ability of GHC base to evolve, instead of just bloating away, is vital.
this creates problems for developers and users. for example, program developed 3 years ago, may be easily incompatible with current ghc version instead, i propose to keep evolving things outside of base, which will allow to use any version of any library with any ghc version. if you build something written in times of ghc 6.2 - you use old version of library. if you build something more modern - you use newer version. cabal automatically handles keeping of multiple versions of same library and using proper version for each build. this technology provides us *both* evolving of libraries and compatibility with old versions -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin
this creates problems for developers and users. for example, program developed 3 years ago, may be easily incompatible with current ghc version
instead, i propose to keep evolving things outside of base, which will allow to use any version of any library with any ghc version. if you build something written in times of ghc 6.2 - you use old version of library. if you build something more modern - you use newer version. cabal automatically handles keeping of multiple versions of same library and using proper version for each build. this technology provides us *both* evolving of libraries and compatibility with old versions
I think it really is offtopic now, but... IMO, Cabal and hackage should treat the base as just another library and should be able to install a fresh base when required. As far as i know, this is achievable to some degree by hands. Making the base "append-only" is not a good solution, IMO.
Hello ArtemGr, Friday, March 16, 2007, 12:47:44 PM, you wrote:
I think it really is offtopic now, but... IMO, Cabal and hackage should treat the base as just another library and should be able to install a fresh base when required. As far as i know, this is achievable to some degree by hands. Making the base "append-only" is not a good solution, IMO.
yes, it is possible but have no any practical meaning because base library anyway shipped together with ghc and there are no alternative versions. if someone will make such versions, these versions may be installed in ghc (may be by hand because Cabal itself uses base :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin
yes, it is possible but have no any practical meaning because base library anyway shipped together with ghc and there are no alternative versions. if someone will make such versions, these versions may be installed in ghc (may be by hand because Cabal itself uses base :)
Base is shipped with GHC, so what? I can fetch the fresh base with darcs and build it. If that doesn't have practical meaning, then speaking of appropriate FPS version being automatically choosen and installed by Cabal has no meaning too, since is not currently possible as well.
Hello ArtemGr, Friday, March 16, 2007, 1:52:24 PM, you wrote:
yes, it is possible but have no any practical meaning because base library anyway shipped together with ghc and there are no alternative versions. if someone will make such versions, these versions may be installed in ghc (may be by hand because Cabal itself uses base :)
Base is shipped with GHC, so what? I can fetch the fresh base with darcs and build it.
base isn't compatible between major ghc versions (6.6/6.8). so you may use only base 2.0 with 6.6 or base 3.0 with 6.8. situation is different for other libraries - you can keep to use fps 0.7 with any ghc version because your program developed against it, or you can upgrade to new version if you need new features -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Bulat Ziganshin
base isn't compatible between major ghc versions (6.6/6.8). so you may use only base 2.0 with 6.6 or base 3.0 with 6.8.
So is a lot of other packages.
situation is different for other libraries - you can keep to use fps 0.7 with any ghc version because your program developed against it,
With any? Are you sure? And even, perhaps, with future versions of GHC, 100 years after?
or you can upgrade to new version if you need new features
If you look at http://www.haskell.org/ghc/docs/latest/html/libraries/index.html you'll see, that base is just a buch of some libraries, maintained together. There's no practical reason why base can't be released separate from GHC. Base is used with other Haskell compilers as well, as you know. If it will be possible to automatically compile a cabalized package against appropriate version of it's dependencies, then i fail to see why it shouldn't be possible to compile against different releases of base as well.
On 3/16/07, Bulat Ziganshin
Hello ArtemGr,
Friday, March 16, 2007, 1:52:24 PM, you wrote:
yes, it is possible but have no any practical meaning because base library anyway shipped together with ghc and there are no alternative versions. if someone will make such versions, these versions may be installed in ghc (may be by hand because Cabal itself uses base :)
Base is shipped with GHC, so what? I can fetch the fresh base with darcs and build it.
base isn't compatible between major ghc versions (6.6/6.8). so you may use only base 2.0 with 6.6 or base 3.0 with 6.8.
This seems wrong to me (though I'm quite new at this, so there could
be something obvious I'm missing). I understand that ghc-6.6 expects
certain types and functions to be defined at particular places within
base, but most names aren't like that. One could declare that base-2.x
defines all the magic names in the places ghc-6.6 expects them, but
other names can be moved around between 2.x and 2.(x+1). Then ghc-6.8
would expect the names where base-3.x places them, and so on.
I just got Cabal to build ghc's base, and the only significant
problems I ran into were
http://hackage.haskell.org/trac/ghc/ticket/1206 and an apparent
expectation that GHC/Prim.hs is found in exactly base-2.0, rather than
just base-*. The following patch seems to work:
[Convince Cabal to build the base library
Jeffrey Yasskin
situation is different for other libraries - you can keep to use fps 0.7 with any ghc version because your program developed against it, or you can upgrade to new version if you need new features
-- Namasté, Jeffrey Yasskin
Hello Jeffrey, Sunday, March 18, 2007, 5:32:21 AM, you wrote:
base isn't compatible between major ghc versions (6.6/6.8). so you may use only base 2.0 with 6.6 or base 3.0 with 6.8.
This seems wrong to me (though I'm quite new at this, so there could be something obvious I'm missing). I understand that ghc-6.6 expects
try to compile base of ghc 6.6 using 6.4 compiler and vice versa. 6.8 is not yet finished, so i guess that differences between base 2.0 and base 3.0 will be much larger that now
So, to solve the immediate problem you're complaining about, it might be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into something like ghc-prim for ghc-6.8 rather than to prevent new modules from being added to the top. Then base can be refactored at a more leisurely pace.
look at http://haskell.org/haskellwiki/Library/Core :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 3/18/07, Bulat Ziganshin
Hello Jeffrey,
Sunday, March 18, 2007, 5:32:21 AM, you wrote:
base isn't compatible between major ghc versions (6.6/6.8). so you may use only base 2.0 with 6.6 or base 3.0 with 6.8.
This seems wrong to me (though I'm quite new at this, so there could be something obvious I'm missing). I understand that ghc-6.6 expects
try to compile base of ghc 6.6 using 6.4 compiler and vice versa. 6.8 is not yet finished, so i guess that differences between base 2.0 and base 3.0 will be much larger that now
That's inconvenient but not a fundamental problem. Say ghc-6.8 gets up to base-3.2 by the time 6.10 is released depending on base-4.0. Then someone wants to add System.ZOMGio to base. They add it to both base-3.3 and base-4.1. Someone who wants to use it needs to specify that they depend on base ">=3.3&&<4.0 || >=4.1", and can probably assume that >=5.0 will also include it.
So, to solve the immediate problem you're complaining about, it might be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into something like ghc-prim for ghc-6.8 rather than to prevent new modules from being added to the top. Then base can be refactored at a more leisurely pace.
look at http://haskell.org/haskellwiki/Library/Core :)
You're depending on the existing base package from these files. You need to pass ghc the -hide-all-packages flag to tell it that you're starting from scratch. Then, even if I copy GHC/* into place, it complains that GhcCore/Base.lhs-boot:16:0: Failed to load interface for `GHC.Prim': it is a member of package base, which is hidden Which is the same problem I ran into. I think you're conflating two different problems: Make ghc-6.8.x support more than ==base-3.0, and make base-3.0 support more than ghc-6.8.x. The second is an admirable goal, but to support upgrading base, you only have to deal with the first. -- Namasté, Jeffrey Yasskin
Hello Jeffrey, Sunday, March 18, 2007, 6:38:11 PM, you wrote:
try to compile base of ghc 6.6 using 6.4 compiler and vice versa. 6.8 is not yet finished, so i guess that differences between base 2.0 and base 3.0 will be much larger that now
That's inconvenient but not a fundamental problem. Say ghc-6.8 gets up to base-3.2 by the time 6.10 is released depending on base-4.0. Then someone wants to add System.ZOMGio to base. They add it to both base-3.3 and base-4.1. Someone who wants to use it needs to specify that they depend on base ">=3.3&&<4.0 || >=4.1", and can probably assume that >>=5.0 will also include it.
of course, this *can* be done. the problem is that it is hard to do, so it is not done. and changes between base versions also include changed interfaces, for example MArray class was changed in 6.6
So, to solve the immediate problem you're complaining about, it might be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into something like ghc-prim for ghc-6.8 rather than to prevent new modules from being added to the top. Then base can be refactored at a more leisurely pace.
look at http://haskell.org/haskellwiki/Library/Core :)
You're depending on the existing base package from these files.
yes, but i tried to do it in that way that omitting Base dependency will be easy. ghc.Prim, btw, is pseudo-module, whose "contents" are generated by compiler automatically from primops.txt.pp Core library is a first try to split GHC.* modules into ghc-specific part (which is not limited to GHC.Prim) and the rest. Ultimately, Core library should include compiler-specific code for several compilers (ghc, nhc, hugs...) and additional code that simulates features omitted in some compilers (arrays, for example). Core library should export API which is the same for all compilers and compiler versions and then Base should import Core and therefore become compiler-independent. so, it just the same plan as your own -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
| > base isn't compatible between major ghc versions (6.6/6.8). so you may | > use only base 2.0 with 6.6 or base 3.0 with 6.8. | | This seems wrong to me (though I'm quite new at this, so there could | be something obvious I'm missing). I understand that ghc-6.6 expects | certain types and functions to be defined at particular places within | base, but most names aren't like that. One could declare that base-2.x | defines all the magic names in the places ghc-6.6 expects them, but | other names can be moved around between 2.x and 2.(x+1). Then ghc-6.8 | would expect the names where base-3.x places them, and so on. That's more or less it. I documented this here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn In the vocabulary of that page * You can change neither the definition nor the location of wired-in things * You can change the definition, but not the location, of known-key or Orig-RdrName things By "location" I mean the name and defining module. The Wiki page tells you how to find out exactly which names fall into which category. Does that help? If anything is unclear, let's improve the Commentary | So, to solve the immediate problem you're complaining about, it might | be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into | something like ghc-prim for ghc-6.8 rather than to prevent new modules | from being added to the top. We have considered doing that. But I don't follow how it would help you here. Simon
On 3/19/07, Simon Peyton-Jones
| > base isn't compatible between major ghc versions (6.6/6.8). so you may | > use only base 2.0 with 6.6 or base 3.0 with 6.8. | | This seems wrong to me (though I'm quite new at this, so there could | be something obvious I'm missing). I understand that ghc-6.6 expects | certain types and functions to be defined at particular places within | base, but most names aren't like that. One could declare that base-2.x | defines all the magic names in the places ghc-6.6 expects them, but | other names can be moved around between 2.x and 2.(x+1). Then ghc-6.8 | would expect the names where base-3.x places them, and so on.
That's more or less it. I documented this here http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn
In the vocabulary of that page * You can change neither the definition nor the location of wired-in things * You can change the definition, but not the location, of known-key or Orig-RdrName things
By "location" I mean the name and defining module.
The Wiki page tells you how to find out exactly which names fall into which category.
Does that help? If anything is unclear, let's improve the Commentary
| So, to solve the immediate problem you're complaining about, it might | be more practical to pull the "bottom" (GHC/Prim*.hs) out of base into | something like ghc-prim for ghc-6.8 rather than to prevent new modules | from being added to the top.
We have considered doing that. But I don't follow how it would help you here.
Thanks, Simon, I hadn't realized it was already possible to release a new base version for the same compiler. The ghc-prim suggestion is probably irrelevant then. To resolve the deadlock around System.FilePath, I propose that Neil be allowed to submit it to base (so that it's definitely in a logical package for ghc-6.8 even if the rest of the refactoring doesn't happen), and then Bulat and anyone else who wants to use it before then should release base-2.1 with System.FilePath backported. Does that sound reasonable? Jeffrey
Hello Jeffrey, Tuesday, March 20, 2007, 7:22:48 AM, you wrote:
To resolve the deadlock around System.FilePath, I propose that Neil be allowed to submit it to base (so that it's definitely in a logical package for ghc-6.8 even if the rest of the refactoring doesn't happen), and then Bulat and anyone else who wants to use it before then should release base-2.1 with System.FilePath backported.
Does that sound reasonable?
it it hardly a solution. supporting one more branch of Base would be a nightmare. FilePath already exists as separate package so i guess that if it will be included in Base 3.0, we will got the same situation as with fps in 6.4/6.6 - separate package should be imported in 6.4 version, but not in 6.6 -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
| To resolve the deadlock around System.FilePath, I propose that Neil be | allowed to submit it to base (so that it's definitely in a logical | package for ghc-6.8 even if the rest of the refactoring doesn't | happen), and then Bulat and anyone else who wants to use it before | then should release base-2.1 with System.FilePath backported. I'm not an active participant in the 'libraries' list, and they are the ones who should decide about putting FilePath in 'base'. Certainly other changes have been made in base, so there is plenty of precedent. But I'm no expert on the FilePath discussion. Simon
participants (4)
-
ArtemGr -
Bulat Ziganshin -
Jeffrey Yasskin -
Simon Peyton-Jones