Ketil Malde wrote:
> What is the "current package"?
The package that you're currently compiling. This now must be known at
compile time.
> My impression was that "from" would
> only be needed when there was ambiguity. (And if I wanted to type
> myself to death, I'd be using Java :-) If you *have* to specify
> package, this makes things a lot less flexible (e.g., moving a module
> from one package to another will break code)
Our current plan is a relatively small delta from the current scheme: as
you say, "from" is only required when there is an ambiguity.
This assumes we keep the current idea of exposed/hidden packages.
Having a default set of exposed packages is terribly convenient when
just firing up GHCi, for example.
In fact, we can imagine three states that a package could be in:
- exposed: the package's modules populate the global module namespace,
explicit "from" imports may be used to resolve ambiguity
- hidden: the package cannot be used at all
- available: the package can be used only by an explicit "from"
import (this is rather like a qualified import at the package
level, and might be useful if you want to use a package with
module names that overlap with local modules).
Currently, packages have a default state of either exposed or hidden.
Cabal ignores the default state, and requires you to say explicitly
which packages you want to be exposed. We don't have the "available"
state, at the moment.
So here are some options:
1. the proposal as it is now, keeping exposed/hidden state in the
package database, don't support "available"
2. Add support for "available". Cons: yet more complexity!
3. Drop the notion of exposed/hidden, all packages are "available".
(except for base?). Cons: lots more typing, very
non-backwards-compatible, still have to list dependencies in
.cabal files.
anyone have any more suggestions? Is there any way to simplify? I
rather feel this design is getting a little unwieldy.
I resist the temptation to discuss syntax too early...
Cheers,
Simon