|
# Package Reorg
|
|
CONVERSION ERROR
|
|
|
|
|
|
|
|
Error: HttpError (HttpExceptionRequest Request {
|
|
In this page we collect proposals and design discussion for
|
|
host = "ghc.haskell.org"
|
|
reorganising the packages that come with compilers, and the contents
|
|
port = 443
|
|
of those packages.
|
|
secure = True
|
|
|
|
requestHeaders = []
|
|
|
|
path = "/trac/ghc/wiki/Commentary/Packages/PackageReorg"
|
|
None of the ideas herein are claimed to belong to any particular
|
|
queryString = "?version=12"
|
|
person, many of the ideas have been extracted from mailing list
|
|
method = "GET"
|
|
discussions, eg.
|
|
proxy = Nothing
|
|
|
|
rawBody = False
|
|
> [ http://www.haskell.org/pipermail/libraries/2006-November/006396.html](http://www.haskell.org/pipermail/libraries/2006-November/006396.html)
|
|
redirectCount = 10
|
|
|
|
responseTimeout = ResponseTimeoutDefault
|
|
|
|
requestVersion = HTTP/1.1
|
|
Some of the points are GHC-specific. Please feel free to insert
|
|
}
|
|
points specific to other compilers.
|
|
(StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 10 Mar 2019 06:59:25 GMT"),("Server","Apache/2.2.22 (Debian)"),("Strict-Transport-Security","max-age=63072000; includeSubDomains"),("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","262"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>403 Forbidden</title>\n</head><body>\n<h1>Forbidden</h1>\n<p>You don't have permission to access /trac/ghc/wiki/Commentary/Packages/PackageReorg\non this server.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at ghc.haskell.org Port 443</address>\n</body></html>\n"))
|
|
|
|
|
|
## Goals
|
|
Original source:
|
|
|
|
|
|
- It would be good to have set of packages that is installed with
|
|
```trac
|
|
every Haskell implementation. This seems to be Bulat's main point
|
|
[[PageOutline]]
|
|
in the thread above.
|
|
= Package Reorg =
|
|
- It should be possible to upgrade any package, even if that package
|
|
|
|
came with the compiler.
|
|
In this page we collect proposals and design discussion for
|
|
|
|
reorganising the packages that come with compilers, and the contents
|
|
## Proposal
|
|
of those packages.
|
|
|
|
|
|
|
|
None of the ideas herein are claimed to belong to any particular
|
|
Here's a straw-man proposal
|
|
person, many of the ideas have been extracted from mailing list
|
|
|
|
discussions, eg.
|
|
|
|
|
|
- There is a set of packages that come with every conforming Haskell
|
|
[http://www.haskell.org/pipermail/libraries/2006-November/006396.html]
|
|
implementation. Let's call these the **Core Packages** to
|
|
|
|
avoid confusion (Bulat called these the "base packages", but that's an
|
|
Some of the points are GHC-specific. Please feel free to insert
|
|
over-used term given that there is a package called `base`).
|
|
points specific to other compilers.
|
|
The good thing about the Core Packages is that
|
|
|
|
users know that they will be there, and they are consistent with
|
|
== Goals ==
|
|
each other.
|
|
|
|
|
|
* It would be good to have set of packages that is installed with
|
|
- Any particular implementation may install more packages by default;
|
|
every Haskell implementation. This seems to be Bulat's main point
|
|
for example GHC will install the `template-haskell` and `stm`
|
|
in the thread above.
|
|
packages. Let's call these the **GHC Install Packages**, **Hugs
|
|
* It should be possible to upgrade any package, even if that package
|
|
Install Packages** etc; the Install Packages are a superset of the
|
|
came with the compiler.
|
|
Core Packages.
|
|
|
|
|
|
== Proposal ==
|
|
### What is in the Core Packages?
|
|
|
|
|
|
Here's a straw-man proposal
|
|
|
|
|
|
The Core Packages are installed with every conforming Haskell implementation. What should be in the Core? There is a tension:
|
|
* There is a set of packages that come with every conforming Haskell
|
|
|
|
implementation. Let's call these the '''Core Packages''' to
|
|
1. **As much as possible**; which means in practice widely-used and reasonably stable packages. It is convenient for programmers to have as much as possible in a consistent, bundle that is (a) known to work together bundle, and (b) known to work on all implementations.
|
|
avoid confusion (Bulat called these the "base packages", but that's an
|
|
1. **As little as possible**; which in practice means enough to run Cabal so that you can run the Setup files that come when downloading new packages. As Ian puts it: the less we force the implementations to come with, the quicker compilation will be when developing, the smaller Debian packages (for example) can be, the lower the disk space requirements to build GHC, the lower the time wasted when a Debian package (for example) build fails and the fewer packages we are tangling up with compiler release schedules.
|
|
over-used term given that there is a package called `base`).
|
|
|
|
The good thing about the Core Packages is that
|
|
|
|
users know that they will be there, and they are consistent with
|
|
There's a real choice here: Bulat wants (1) and Ian wants (2).
|
|
each other.
|
|
|
|
|
|
|
|
* Any particular implementation may install more packages by default;
|
|
Initial stab at (1):
|
|
for example GHC will install the `template-haskell` and `stm`
|
|
|
|
packages. Let's call these the '''GHC Install Packages''', '''Hugs
|
|
- `base`
|
|
Install Packages''' etc; the Install Packages are a superset of the
|
|
- `haskell98`
|
|
Core Packages.
|
|
- `Cabal`
|
|
|
|
- `filepath`
|
|
=== What is in the Core Packages? ===
|
|
|
|
|
|
|
|
The Core Packages are installed with every conforming Haskell implementation. What should be in the Core? There is a tension:
|
|
Initial stab at (2):
|
|
|
|
|
|
1. '''As much as possible'''; which means in practice widely-used and reasonably stable packages. It is convenient for programmers to have as much as possible in a consistent, bundle that is (a) known to work together bundle, and (b) known to work on all implementations. [[BR]][[BR]]
|
|
- `base`
|
|
2. '''As little as possible'''; which in practice means enough to run Cabal so that you can run the Setup files that come when downloading new packages. As Ian puts it: the less we force the implementations to come with, the quicker compilation will be when developing, the smaller Debian packages (for example) can be, the lower the disk space requirements to build GHC, the lower the time wasted when a Debian package (for example) build fails and the fewer packages we are tangling up with compiler release schedules.
|
|
- `Cabal`
|
|
|
|
- `haskell98`
|
|
There's a real choice here: Bulat wants (1) and Ian wants (2).
|
|
- Some `regex` packages (precisely which?)
|
|
|
|
- `unix` or `Win32`
|
|
Initial stab at (1):
|
|
- `parsec`
|
|
|
|
- `mtl`
|
|
* `base`
|
|
- `time`
|
|
* `Cabal`
|
|
- `network`
|
|
* `haskell98`
|
|
|
|
* Some `regex` packages (precisely which?)
|
|
|
|
* `unix` or `Win32`
|
|
Questionable:
|
|
* `parsec`
|
|
|
|
* `mtl`
|
|
- `QuickCheck`
|
|
* `time`
|
|
- `HUnit`
|
|
* `network`
|
|
|
|
* `QuickCheck` (questionable)
|
|
|
|
* `HUnit` (questionable)
|
|
Bulat: i think that all regex packages should be included and of course libs that helps testing. overall, it should be any general-purpose lib that porters accept (emlarging these sets makes users live easier, and porters live harder)
|
|
|
|
|
|
Initial stab at (2):
|
|
### The base package
|
|
* `base`
|
|
|
|
* `haskell98`
|
|
|
|
* `Cabal`
|
|
The base package is a bit special
|
|
* `filepath`
|
|
|
|
|
|
- Package `base` is rather big at the moment.
|
|
Bulat: i think that all regex packages should be included and of course libs that helps testing. overall, it should be any general-purpose lib that porters accept (emlarging these sets makes users live easier, and porters live harder)
|
|
|
|
|
|
- From a user's point of view it would be nicer to give it a
|
|
=== The base package ===
|
|
compiler-independent API. (A module like `GHC.Exts` would move to
|
|
|
|
a new package `ghc-base`.)
|
|
The base package is a bit special
|
|
|
|
|
|
|
|
* Package `base` is rather big at the moment.
|
|
Thinking of GHC alone for a moment, we could have a package `ghc-base`
|
|
|
|
(which is pretty much the current `base`) and a thin wrapper package
|
|
* From a user's point of view it would be nicer to give it a
|
|
`base` that re-exposes some, but not all, of what `ghc-base` exposes.
|
|
compiler-independent API. (A module like `GHC.Exts` would move to
|
|
To support this re-exposing, we need a small fix to both GHC and
|
|
a new package `ghc-base`.)
|
|
Cabal, but one that is independently desirable.
|
|
|
|
|
|
Thinking of GHC alone for a moment, we could have a package `ghc-base`
|
|
|
|
(which is pretty much the current `base`) and a thin wrapper package
|
|
Similarly, Hugs could build `hugs-base` from the same souce code, by
|
|
`base` that re-exposes some, but not all, of what `ghc-base` exposes.
|
|
using CPP-ery, exactly as now. The thin `base` wrapper package
|
|
To support this re-exposing, we need a small fix to both GHC and
|
|
would not change.
|
|
Cabal, but one that is independently desirable.
|
|
|
|
|
|
|
|
Similarly, Hugs could build `hugs-base` from the same souce code, by
|
|
To make `base` smaller, we could remove stuff, and put it into
|
|
using CPP-ery, exactly as now. The thin `base` wrapper package
|
|
separate packages. But be careful: packages cannot be cyclic, so
|
|
would not change.
|
|
anything that is moved out can't be used in `base`.
|
|
|
|
Some chunks that would currently be easy to split off are:
|
|
To make `base` smaller, we could remove stuff, and put it into
|
|
|
|
separate packages. But be careful: packages cannot be cyclic, so
|
|
- Data.ByteString.\* (plus future packed Char strings)
|
|
anything that is moved out can't be used in `base`.
|
|
- Control.Applicative (?), Data.Foldable, Data.Monoid (?), Data.Traversable, Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree
|
|
Some chunks that would currently be easy to split off are:
|
|
- System.Console.GetOpt
|
|
* Data.!ByteString.* (plus future packed Char strings)
|
|
- Text.PrettyPrint.\*
|
|
* Control.Applicative (?), Data.Foldable, Data.Monoid (?), Data.Traversable, Data.Graph, Data.!IntMap, Data.!IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree
|
|
- Text.Printf
|
|
* System.Console.!GetOpt
|
|
|
|
* Text.!PrettyPrint.*
|
|
|
|
* Text.Printf
|
|
Some other things, such as arrays and concurrency, have nothing else depending on them, but are so closely coupled with GHC's internals that extracting them would require exposing these internals in the interface of `base`.
|
|
Some other things, such as arrays and concurrency, have nothing else depending on them, but are so closely coupled with GHC's internals that extracting them would require exposing these internals in the interface of `base`.
|
|
|
|
|
|
|
|
Bulat: my ArrayRef library contains portable implementation of arrays. there is only thin ghc/hugs-specific layer which should be provided by ghcbase/hugsbase libs. except for MPTC problem (IArray/MArray classes has multiple parameters), this library should be easily portable to any other haskell compiler
|
|
Bulat: my ArrayRef library contains portable implementation of arrays. there is only thin ghc/hugs-specific layer which should be provided by ghcbase/hugsbase libs. except for MPTC problem (IArray/MArray classes has multiple parameters), this library should be easily portable to any other haskell compiler
|
|
|
|
|
|
=== Other packages ===
|
|
### Other packages
|
|
|
|
|
|
Other non-core packages would probably have their own existence. That
|
|
|
|
is, they don't come with an implementation; instead you use
|
|
Other non-core packages would probably have their own existence. That
|
|
`cabal-get`, or some other mechanism, such as your OS's package
|
|
is, they don't come with an implementation; instead you use
|
|
manager. Some of these currently come with GHC, and would no longer do
|
|
`cabal-get`, or some other mechanism, such as your OS's package
|
|
so
|
|
manager. Some of these currently come with GHC, and would no longer do
|
|
|
|
so
|
|
* `GLUT`
|
|
|
|
* `ALUT`
|
|
- `GLUT`
|
|
* `OpenAL`
|
|
- `ALUT`
|
|
* `OpenGL`
|
|
- `OpenAL`
|
|
* `HGL`
|
|
- `OpenGL`
|
|
* `HUnit`
|
|
- `HGL`
|
|
* `ObjectIO`
|
|
- `HUnit`
|
|
* `X11`
|
|
- `ObjectIO`
|
|
* `arrows`
|
|
- `X11`
|
|
* `cgi`
|
|
- `arrows`
|
|
* `fgl`
|
|
- `cgi`
|
|
* `html`
|
|
- `fgl`
|
|
* `xhtml`
|
|
- `html`
|
|
|
|
- `xhtml`
|
|
Bulat: i propose to unbundle only graphics/sound libs because these solves particular problems and tends to be large, non-portable (?) and just legacy ones - like ObjectIO. we should keep everything small & general purpose, including HUnit, arraows, fgl, html and xhtml, and include even more:
|
|
|
|
|
|
|
|
ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, QuickCheck, monads
|
|
Bulat: i propose to unbundle only graphics/sound libs because these solves particular problems and tends to be large, non-portable (?) and just legacy ones - like ObjectIO. we should keep everything small & general purpose, including HUnit, arraows, fgl, html and xhtml, and include even more:
|
|
|
|
|
|
== Testing ==
|
|
|
|
|
|
ByteString, regex-\*, Edison, Filepath, MissingH, NewBinary, QuickCheck, monads
|
|
We should separate out package-specifc tests, which should be part of
|
|
|
|
the repository for each package. Currently they are all squashed
|
|
## Testing
|
|
together into the testsuite repository.
|
|
|
|
|
|
|
|
|
|
We should separate out package-specifc tests, which should be part of
|
|
== Implementation-specific notes ==
|
|
the repository for each package. Currently they are all squashed
|
|
=== Notes about GHC ===
|
|
together into the testsuite repository.
|
|
|
|
|
|
Currently GHC installs a set of packages by default: base, stm,
|
|
## Implementation-specific notes
|
|
template-haskell, cabal, haskel98, readline, 3 of the 5 regex
|
|
|
|
packages. These are exactly the libraries required to build GHC.
|
|
### Notes about GHC
|
|
That shouldn't be the criterion. This set of packages are currently
|
|
|
|
called GHC's "core packages", but should be renamed to '''GHC Boot
|
|
|
|
Packages'''.
|
|
Currently GHC installs a set of packages by default: base, stm,
|
|
|
|
template-haskell, cabal, haskel98, readline, 3 of the 5 regex
|
|
One reason we do this is because it means that every GHC installation
|
|
packages. These are exactly the libraries required to build GHC.
|
|
can build GHC. Less configure-script hacking. (NB: even today if you
|
|
That shouldn't be the criterion. This set of packages are currently
|
|
upgrade any of these packages, and then build GHC, the build might
|
|
called GHC's "core packages", but should be renamed to **GHC Boot
|
|
fail because the CPP-ery in GHC's sources uses only the version number
|
|
Packages**.
|
|
of GHC, not the version number of the package.)
|
|
|
|
|
|
|
|
Still, for convenience we'd probably arrange that the GHC Install
|
|
One reason we do this is because it means that every GHC installation
|
|
Packages included all the GHC Boot Packages.
|
|
can build GHC. Less configure-script hacking. (NB: even today if you
|
|
|
|
upgrade any of these packages, and then build GHC, the build might
|
|
Every GHC installation must include packages: `base` and
|
|
fail because the CPP-ery in GHC's sources uses only the version number
|
|
`template-haskell`, else GHC itself will not work. (In fact
|
|
of GHC, not the version number of the package.)
|
|
`haskell98` is also required, but only because it is linked by
|
|
|
|
default.)
|
|
|
|
|
|
Still, for convenience we'd probably arrange that the GHC Install
|
|
So GHC's Install Packages would be the Core Packages plus
|
|
Packages included all the GHC Boot Packages.
|
|
* `template-haskell`
|
|
|
|
* `stm`
|
|
|
|
* `readline`
|
|
Every GHC installation must include packages: `base` and
|
|
|
|
`template-haskell`, else GHC itself will not work. (In fact
|
|
You can upgrade any package, including `base` after installing GHC.
|
|
`haskell98` is also required, but only because it is linked by
|
|
However, you need to take care. You must not change a number of things
|
|
default.)
|
|
that GHC "knows about". In particular, these things must not change
|
|
|
|
* Name
|
|
|
|
* Defining module
|
|
So GHC's Install Packages would be the Core Packages plus
|
|
GHC knows even more about some things, where you must not change
|
|
|
|
* Type signature
|
|
- `template-haskell`
|
|
* For data types, the names, types, and order of the constructors
|
|
- `stm`
|
|
The latter group are confined to packages base and template-haskell.
|
|
- `readline`
|
|
|
|
|
|
(Note: a few other packages are used by tests in GHC's test suite,
|
|
|
|
currently: `mtl`, `QuickCheck`. We should probably eliminate the mtl
|
|
You can upgrade any package, including `base` after installing GHC.
|
|
dependency; but `QuickCheck` is used as part of the test infrastructure
|
|
However, you need to take care. You must not change a number of things
|
|
itself, so we'll make it a GHC Boot Package.)
|
|
that GHC "knows about". In particular, these things must not change
|
|
|
|
|
|
=== Notes about Hugs ===
|
|
- Name
|
|
|
|
- Defining module
|
|
Recent distributions of Hugs come in two sizes, jumbo and minimal.
|
|
|
|
Minimal distributions include only the packages `base`, `haskell98` and `Cabal`.
|
|
|
|
(Hugs includes another package `hugsbase` containing interfaces to Hugs primitives.)
|
|
GHC knows even more about some things, where you must not change
|
|
The requirements for this set are to
|
|
|
|
* run Haskell 98 programs
|
|
- Type signature
|
|
* allow packages to be added and upgraded using Cabal
|
|
- For data types, the names, types, and order of the constructors
|
|
(Currently `cpphs` is a Haskell 98 program, so the latter implies the former.)
|
|
|
|
|
|
|
|
It should be possible to upgrade even the core packages using Cabal.
|
|
The latter group are confined to packages base and template-haskell.
|
|
|
|
|
|
``` |
|
|
|
|
|
(Note: a few other packages are used by tests in GHC's test suite,
|
|
|
|
currently: `mtl`, `QuickCheck`. We should probably eliminate the mtl
|
|
|
|
dependency; but `QuickCheck` is used as part of the test infrastructure
|
|
|
|
itself, so we'll make it a GHC Boot Package.)
|
|
|
|
|
|
|
|
### Notes about Hugs
|
|
|
|
|
|
|
|
|
|
|
|
Recent distributions of Hugs come in two sizes, jumbo and minimal.
|
|
|
|
Minimal distributions include only the packages `base`, `haskell98` and `Cabal`.
|
|
|
|
(Hugs includes another package `hugsbase` containing interfaces to Hugs primitives.)
|
|
|
|
The requirements for this set are to
|
|
|
|
|
|
|
|
- run Haskell 98 programs
|
|
|
|
- allow packages to be added and upgraded using Cabal
|
|
|
|
|
|
|
|
|
|
|
|
(Currently `cpphs` is a Haskell 98 program, so the latter implies the former.)
|
|
|
|
|
|
|
|
|
|
|
|
It should be possible to upgrade even the core packages using Cabal. |
|
|