|
CONVERSION ERROR
|
|
# Package Reorg
|
|
|
|
|
|
Error: HttpError (HttpExceptionRequest Request {
|
|
|
|
host = "ghc.haskell.org"
|
|
In this page we collect proposals and design discussion for
|
|
port = 443
|
|
reorganising the packages that come with compilers, and the contents
|
|
secure = True
|
|
of those packages.
|
|
requestHeaders = []
|
|
|
|
path = "/trac/ghc/wiki/Commentary/Packages/PackageReorg"
|
|
|
|
queryString = "?version=17"
|
|
None of the ideas herein are claimed to belong to any particular
|
|
method = "GET"
|
|
person, many of the ideas have been extracted from mailing list
|
|
proxy = Nothing
|
|
discussions, eg.
|
|
rawBody = False
|
|
|
|
redirectCount = 10
|
|
> [ http://www.haskell.org/pipermail/libraries/2006-November/006396.html](http://www.haskell.org/pipermail/libraries/2006-November/006396.html)
|
|
responseTimeout = ResponseTimeoutDefault
|
|
|
|
requestVersion = HTTP/1.1
|
|
|
|
}
|
|
Some of the points are GHC-specific. Please feel free to insert
|
|
(StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 10 Mar 2019 06:59:28 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"))
|
|
points specific to other compilers.
|
|
|
|
|
|
Original source:
|
|
## Goals
|
|
|
|
|
|
```trac
|
|
- It would be good to have set of 'core' packages that is installed with
|
|
[[PageOutline]]
|
|
every Haskell implementation. More on this at [PackageReorg/Rationale](commentary/packages/package-reorg/rationale) page
|
|
= Package Reorg =
|
|
- Forwards compatibility. Users would like their programs written against the 'core' packages to continue to work, without
|
|
|
|
modification to source text or build system, after upgrading the
|
|
In this page we collect proposals and design discussion for
|
|
compiler, or its packages, or switching to a different compiler.
|
|
reorganising the packages that come with compilers, and the contents
|
|
- Backwards compatibility. Users would like to be able to take a
|
|
of those packages.
|
|
program written against some version of the 'core' packages, and
|
|
|
|
build it with an older compiler, accepting that they may have to
|
|
None of the ideas herein are claimed to belong to any particular
|
|
install newer versions of the 'core' packages in order to do so.
|
|
person, many of the ideas have been extracted from mailing list
|
|
|
|
discussions, eg.
|
|
|
|
|
|
It may not be possible to fully achieve these goals (in particular, backwards compatibility), but that does not mean we should not aim for them.
|
|
[http://www.haskell.org/pipermail/libraries/2006-November/006396.html]
|
|
|
|
|
|
## Proposal
|
|
Some of the points are GHC-specific. Please feel free to insert
|
|
|
|
points specific to other compilers.
|
|
|
|
|
|
Here's a straw-man proposal
|
|
== Goals ==
|
|
|
|
|
|
|
|
* It would be good to have set of 'core' packages that is installed with
|
|
- There is a set of packages that come with every conforming Haskell
|
|
every Haskell implementation. More on this at PackageReorg/Rationale page
|
|
implementation. Let's call these the **Core Packages** to
|
|
* Forwards compatibility. Users would like their programs written against the 'core' packages to continue to work, without
|
|
avoid confusion (Bulat called these the "base packages", but that's an
|
|
modification to source text or build system, after upgrading the
|
|
over-used term given that there is a package called `base`).
|
|
compiler, or its packages, or switching to a different compiler.
|
|
The good thing about the Core Packages is that
|
|
* Backwards compatibility. Users would like to be able to take a
|
|
users know that they will be there, and they are consistent with
|
|
program written against some version of the 'core' packages, and
|
|
each other.
|
|
build it with an older compiler, accepting that they may have to
|
|
|
|
install newer versions of the 'core' packages in order to do so.
|
|
- Any particular implementation may install more packages by default;
|
|
|
|
for example GHC will install the `template-haskell` and `stm`
|
|
It may not be possible to fully achieve these goals (in particular, backwards compatibility), but that does not mean we should not aim for them.
|
|
packages. Let's call these the **GHC Install Packages**, **Hugs
|
|
|
|
Install Packages** etc; the Install Packages are a superset of the
|
|
== Proposal ==
|
|
Core Packages.
|
|
|
|
|
|
Here's a straw-man proposal
|
|
### What is in the Core Packages?
|
|
|
|
|
|
* There is a set of packages that come with every conforming Haskell
|
|
|
|
implementation. Let's call these the '''Core Packages''' to
|
|
The Core Packages are installed with every conforming Haskell implementation. What should be in the Core? There is a tension:
|
|
avoid confusion (Bulat called these the "base packages", but that's an
|
|
|
|
over-used term given that there is a package called `base`).
|
|
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.
|
|
The good thing about the Core Packages is that
|
|
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.
|
|
users know that they will be there, and they are consistent with
|
|
|
|
each other.
|
|
|
|
|
|
There's a real choice here: Bulat wants (1) and Ian wants (2).
|
|
* Any particular implementation may install more packages by default;
|
|
|
|
for example GHC will install the `template-haskell` and `stm`
|
|
|
|
packages. Let's call these the '''GHC Install Packages''', '''Hugs
|
|
Initial stab at (1):
|
|
Install Packages''' etc; the Install Packages are a superset of the
|
|
|
|
Core Packages.
|
|
- `base`
|
|
|
|
- `Cabal`
|
|
=== What is in the Core Packages? ===
|
|
- `haskell98`
|
|
|
|
- Some `regex` packages (precisely which?)
|
|
The Core Packages are installed with every conforming Haskell implementation. What should be in the Core? There is a tension:
|
|
- `unix` or `Win32`. Questionable, partly because it means the Core interface becomes platform-dependent; and partly because `Win32` would double the size of the Hugs distribution.
|
|
|
|
- `parsec`
|
|
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]]
|
|
- `mtl`
|
|
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.
|
|
- `time`
|
|
|
|
- `network`
|
|
There's a real choice here: Bulat wants (1) and Ian wants (2).
|
|
- `QuickCheck` (questionable)
|
|
|
|
- `HUnit` (questionable)
|
|
Initial stab at (1):
|
|
|
|
|
|
|
|
* `base`
|
|
Initial stab at (2):
|
|
* `Cabal`
|
|
|
|
* `haskell98`
|
|
- `base`
|
|
* Some `regex` packages (precisely which?)
|
|
- `haskell98`
|
|
* `unix` or `Win32`. Questionable, partly because it means the Core interface becomes platform-dependent; and partly because `Win32` would double the size of the Hugs distribution.
|
|
- `Cabal`
|
|
* `parsec`
|
|
- `filepath` (?)
|
|
* `mtl`
|
|
|
|
* `time`
|
|
|
|
* `network`
|
|
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 (enlarging this set makes users live easier, and porters live harder)
|
|
* `QuickCheck` (questionable)
|
|
|
|
* `HUnit` (questionable)
|
|
|
|
|
|
about unix/win32 - these libs provide access to OS internals, not some everywhere-portable API. moreover, other world-interfacing libs (i/o, networking) should use APIs provided by these libs with a conditional compilation (CPPery) tricks in order to provide portable APIs! current situation where such libs use FFI isn't ideal. WinHugs size problem is rather technical - it includes a lot of DLLs which contains almost the same code
|
|
Initial stab at (2):
|
|
|
|
* `base`
|
|
|
|
* `haskell98`
|
|
i agree to start with minimal stub, and then proceed with discussing inclusion of each library. what we need now is requirements to include library in this set and lifetime support procedure. so:
|
|
* `Cabal`
|
|
|
|
* `filepath` (?)
|
|
### Requirements to libraries to be included in core set
|
|
|
|
|
|
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 (enlarging this set makes users live easier, and porters live harder)
|
|
- BSD-licensed, and even belongs to Haskell community?
|
|
|
|
- portable (is sense of compiler and OS), may be just Haskell' compatible?
|
|
about unix/win32 - these libs provide access to OS internals, not some everywhere-portable API. moreover, other world-interfacing libs (i/o, networking) should use APIs provided by these libs with a conditional compilation (CPPery) tricks in order to provide portable APIs! current situation where such libs use FFI isn't ideal. WinHugs size problem is rather technical - it includes a lot of DLLs which contains almost the same code
|
|
- already widely used
|
|
|
|
- shouldn't duplicate existing core libs functionality (?)
|
|
i agree to start with minimal stub, and then proceed with discussing inclusion of each library. what we need now is requirements to include library in this set and lifetime support procedure. so:
|
|
|
|
|
|
|
|
=== Requirements to libraries to be included in core set ===
|
|
Exact inclusion, support and exclusion processes?
|
|
|
|
|
|
* BSD-licensed, and even belongs to Haskell community?
|
|
### The base package
|
|
* portable (is sense of compiler and OS), may be just Haskell' compatible?
|
|
|
|
* already widely used
|
|
|
|
* shouldn't duplicate existing core libs functionality (?)
|
|
The base package is a bit special
|
|
|
|
|
|
Exact inclusion, support and exclusion processes?
|
|
- Package `base` is rather big at the moment.
|
|
|
|
|
|
=== The base package ===
|
|
- From a user's point of view it would be nicer to give it a
|
|
|
|
compiler-independent API. (A module like `GHC.Exts` would move to
|
|
The base package is a bit special
|
|
a new package `ghc-base`.)
|
|
|
|
|
|
* Package `base` is rather big at the moment.
|
|
|
|
|
|
Thinking of GHC alone for a moment, we could have a package `ghc-base`
|
|
* From a user's point of view it would be nicer to give it a
|
|
(which is pretty much the current `base`) and a thin wrapper package
|
|
compiler-independent API. (A module like `GHC.Exts` would move to
|
|
`base` that re-exposes some, but not all, of what `ghc-base` exposes.
|
|
a new package `ghc-base`.)
|
|
To support this re-exposing, we need a small fix to both GHC and
|
|
|
|
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
|
|
|
|
`base` that re-exposes some, but not all, of what `ghc-base` exposes.
|
|
Similarly, Hugs could build `hugs-base` from the same souce code, by
|
|
To support this re-exposing, we need a small fix to both GHC and
|
|
using CPP-ery, exactly as now. The thin `base` wrapper package
|
|
Cabal, but one that is independently desirable.
|
|
would not change.
|
|
|
|
|
|
Similarly, Hugs could build `hugs-base` from the same souce code, by
|
|
|
|
using CPP-ery, exactly as now. The thin `base` wrapper package
|
|
To make `base` smaller, we could remove stuff, and put it into
|
|
would not change.
|
|
separate packages. But be careful: packages cannot be cyclic, so
|
|
|
|
anything that is moved out can't be used in `base`.
|
|
To make `base` smaller, we could remove stuff, and put it into
|
|
Some chunks that would currently be easy to split off are:
|
|
separate packages. But be careful: packages cannot be cyclic, so
|
|
|
|
anything that is moved out can't be used in `base`.
|
|
- Data.ByteString.\* (plus future packed Char strings)
|
|
Some chunks that would currently be easy to split off are:
|
|
- Control.Applicative (?), Data.Foldable, Data.Monoid (?), Data.Traversable, Data.Graph, Data.IntMap, Data.IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree
|
|
* Data.!ByteString.* (plus future packed Char strings)
|
|
- System.Console.GetOpt
|
|
* Control.Applicative (?), Data.Foldable, Data.Monoid (?), Data.Traversable, Data.Graph, Data.!IntMap, Data.!IntSet, Data.Map, Data.Sequence, Data.Set, Data.Tree
|
|
- Text.PrettyPrint.\*
|
|
* System.Console.!GetOpt
|
|
- Text.Printf
|
|
* 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 non-core packages would probably have their own existence. That
|
|
See also [BaseSplit](base-split).
|
|
is, they don't come with an implementation; instead you use
|
|
|
|
`cabal-get`, or some other mechanism, such as your OS's package
|
|
### Other packages
|
|
manager. Some of these currently come with GHC, and would no longer do
|
|
|
|
so
|
|
|
|
|
|
Other non-core packages would probably have their own existence. That
|
|
* `GLUT`
|
|
is, they don't come with an implementation; instead you use
|
|
* `ALUT`
|
|
`cabal-get`, or some other mechanism, such as your OS's package
|
|
* `OpenAL`
|
|
manager. Some of these currently come with GHC, and would no longer do
|
|
* `OpenGL`
|
|
so
|
|
* `HGL`
|
|
|
|
* `HUnit`
|
|
- `GLUT`
|
|
* `ObjectIO`
|
|
- `ALUT`
|
|
* `X11`
|
|
- `OpenAL`
|
|
* `arrows`
|
|
- `OpenGL`
|
|
* `cgi`
|
|
- `HGL`
|
|
* `fgl`
|
|
- `HUnit`
|
|
* `html`
|
|
- `ObjectIO`
|
|
* `xhtml`
|
|
- `X11`
|
|
|
|
- `arrows`
|
|
Bulat: i propose to unbundle only graphics/sound libs because these solves particular problems and tends to be large, non-portable (?) and some are just legacy ones - like ObjectIO. we should keep everything small & general purpose, including HUnit, arrows, fgl, html and xhtml, and include even more: ByteString, regex-*, Edison, Filepath, MissingH, NewBinary, QuickCheck, monads
|
|
- `cgi`
|
|
|
|
- `fgl`
|
|
== Testing ==
|
|
- `html`
|
|
|
|
- `xhtml`
|
|
We should separate out package-specifc tests, which should be part of
|
|
|
|
the repository for each package. Currently they are all squashed
|
|
|
|
together into the testsuite repository.
|
|
Bulat: i propose to unbundle only graphics/sound libs because these solves particular problems and tends to be large, non-portable (?) and some are just legacy ones - like ObjectIO. we should keep everything small & general purpose, including HUnit, arrows, fgl, html and xhtml, and include even more: ByteString, regex-\*, Edison, Filepath, MissingH, NewBinary, QuickCheck, monads
|
|
|
|
|
|
|
|
## Testing
|
|
== Implementation-specific notes ==
|
|
|
|
=== Notes about GHC ===
|
|
|
|
|
|
We should separate out package-specifc tests, which should be part of
|
|
Currently GHC installs a set of packages by default: base, stm,
|
|
the repository for each package. Currently they are all squashed
|
|
template-haskell, cabal, haskel98, readline, 3 of the 5 regex
|
|
together into the testsuite repository.
|
|
packages. These are exactly the libraries required to build GHC.
|
|
|
|
That shouldn't be the criterion. This set of packages are currently
|
|
## Implementation-specific notes
|
|
called GHC's "core packages", but should be renamed to '''GHC Boot
|
|
|
|
Packages'''.
|
|
### Notes about GHC
|
|
|
|
|
|
One reason we do this is because it means that every GHC installation
|
|
|
|
can build GHC. Less configure-script hacking. (NB: even today if you
|
|
Currently GHC installs a set of packages by default: base, stm,
|
|
upgrade any of these packages, and then build GHC, the build might
|
|
template-haskell, cabal, haskel98, readline, 3 of the 5 regex
|
|
fail because the CPP-ery in GHC's sources uses only the version number
|
|
packages. These are exactly the libraries required to build GHC.
|
|
of GHC, not the version number of the package.)
|
|
That shouldn't be the criterion. This set of packages are currently
|
|
|
|
called GHC's "core packages", but should be renamed to **GHC Boot
|
|
Still, for convenience we'd probably arrange that the GHC Install
|
|
Packages**.
|
|
Packages included all the GHC Boot Packages.
|
|
|
|
|
|
|
|
Every GHC installation must include packages: `base` and
|
|
One reason we do this is because it means that every GHC installation
|
|
`template-haskell`, else GHC itself will not work. (In fact
|
|
can build GHC. Less configure-script hacking. (NB: even today if you
|
|
`haskell98` is also required, but only because it is linked by
|
|
upgrade any of these packages, and then build GHC, the build might
|
|
default.)
|
|
fail because the CPP-ery in GHC's sources uses only the version number
|
|
|
|
of GHC, not the version number of the package.)
|
|
So GHC's Install Packages would be the Core Packages plus
|
|
|
|
* `template-haskell`
|
|
|
|
* `stm`
|
|
Still, for convenience we'd probably arrange that the GHC Install
|
|
* `readline`
|
|
Packages included all the GHC Boot Packages.
|
|
|
|
|
|
You can upgrade any package, including `base` after installing GHC.
|
|
|
|
However, you need to take care. You must not change a number of things
|
|
Every GHC installation must include packages: `base` and
|
|
that GHC "knows about". In particular, these things must not change
|
|
`template-haskell`, else GHC itself will not work. (In fact
|
|
* Name
|
|
`haskell98` is also required, but only because it is linked by
|
|
* Defining module
|
|
default.)
|
|
GHC knows even more about some things, where you must not change
|
|
|
|
* Type signature
|
|
|
|
* For data types, the names, types, and order of the constructors
|
|
So GHC's Install Packages would be the Core Packages plus
|
|
The latter group are confined to packages base and template-haskell.
|
|
|
|
|
|
- `template-haskell`
|
|
(Note: a few other packages are used by tests in GHC's test suite,
|
|
- `stm`
|
|
currently: `mtl`, `QuickCheck`. We should probably eliminate the mtl
|
|
- `readline`
|
|
dependency; but `QuickCheck` is used as part of the test infrastructure
|
|
|
|
itself, so we'll make it a GHC Boot Package.)
|
|
|
|
|
|
You can upgrade any package, including `base` after installing GHC.
|
|
=== Notes about Hugs ===
|
|
However, you need to take care. You must not change a number of things
|
|
|
|
that GHC "knows about". In particular, these things must not change
|
|
Recent distributions of Hugs come in two sizes, jumbo and minimal.
|
|
|
|
Minimal distributions include only the packages `base`, `haskell98` and `Cabal`.
|
|
- Name
|
|
(Hugs includes another package `hugsbase` containing interfaces to Hugs primitives.)
|
|
- Defining module
|
|
The requirements for this set are to
|
|
|
|
* run Haskell 98 programs
|
|
|
|
* allow packages to be added and upgraded using Cabal
|
|
GHC knows even more about some things, where you must not change
|
|
(Currently `cpphs` is a Haskell 98 program, so the latter implies the former.)
|
|
|
|
|
|
- Type signature
|
|
It should be possible to upgrade even the core packages using Cabal.
|
|
- For data types, the names, types, and order of the constructors
|
|
|
|
|
|
``` |
|
|
|
|
|
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. |