John Meacham wrote:
Package names should never appear in source files IMHO. if a package
name is in the source file, then you might as well make it part of the
module name. packages exist for 'meta-organization' of code. A way to
deal with mapping code _outside_ of the language itself, putting
Brian Hulley wrote:
Simon Peyton-Jones wrote:
compulsory. Perhaps you could improve the wording to make it more
unambiguous?
Indeed, if we've converged, would you like to fold into our draft
whatever you think is useful from yours?
[snip]
Therefore it seems best to just leave them as
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
Niklas Broberg wrote:
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
Package names should never appear in source files IMHO. if a package
name is in the source file, then you might as well make it part of the
module name. packages exist for 'meta-organization' of code. A way to
deal with mapping code _outside_ of the language itself, putting
packages inside the
Brian Hulley wrote:
Simon Peyton-Jones wrote:
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
I think the following is a non-question:
An open question: if A.B.C is in the package being compiled,
and in an exposed package, and you say import A.B.C,
do you get an error
