Simon Peyton-Jones [EMAIL PROTECTED] writes:
Brian Hulley wrote:
| import A.B.C( T1 ) from foo
| import A.B.C( T2 ) from bar
| type S = A.B.C.T1 - A.B.C.T2
| I'd suggest that the above should give a compiler error that A.B.C is
| ambiguous (as a qualifier), rather than allowing T1
Simon Peyton-Jones [EMAIL PROTECTED] writes:
Brian Hulley wrote:
| import A.B.C( T1 ) from foo
| import A.B.C( T2 ) from bar
| type S = A.B.C.T1 - A.B.C.T2
| I'd suggest that the above should give a compiler error that A.B.C is
| ambiguous (as a qualifier), rather than allowing T1
[EMAIL PROTECTED] wrote:
Simon Peyton-Jones [EMAIL PROTECTED] writes:
Brian Hulley wrote:
| import A.B.C( T1 ) from foo
| import A.B.C( T2 ) from bar
| type S = A.B.C.T1 - A.B.C.T2
| I'd suggest that the above should give a compiler error that A.B.C is
| ambiguous (as a qualifier),
Brian
| Actually re-reading my post I realised I may have sounded a bit
negative
| about the hard work you'd done to collate the various responses to
form the
| wiki proposal - my apologies
Thanks -- email is a fragile medium!
| I've followed your suggestion and made a separate page at
|
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
Simon Peyton-Jones wrote:
Brian
Actually re-reading my post I realised I may have sounded a bit
negative about the hard work you'd done to collate the various
responses to form the wiki proposal - my apologies
Thanks -- email is a fragile medium!
I've followed your suggestion and made a
| 1) Qualified names:
|
| import A.B.C( T1 ) from foo
| import A.B.C( T2 ) from bar
| type S = A.B.C.T1 - A.B.C.T2
|
| I'd suggest that the above should give a compiler error that A.B.C is
| ambiguous (as a qualifier), rather than allowing T1 to disambiguate
it,
| because otherwise it
Simon Peyton-Jones wrote:
1) Qualified names:
import A.B.C( T1 ) from foo
import A.B.C( T2 ) from bar
type S = A.B.C.T1 - A.B.C.T2
I'd suggest that the above should give a compiler error that A.B.C is
ambiguous (as a qualifier), rather than allowing T1 to disambiguate
it, because
On 2006-07-06, Simon Marlow [EMAIL PROTECTED] wrote:
a. we could put package names in module names as you suggest. But
apart from sacrificing the second principle, this doesn't let
you import a module from a package without specifying the exact
version of the package == BAD.
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
On Wed, Jul 05, 2006 at 01:03:01AM +0100, Brian Hulley wrote:
Simon Peyton-Jones wrote:
Concerning other mail on this subject, which has been v useful, I've
revised the Wiki page (substantially) to take it into account.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Further input
Brian Hulley [EMAIL PROTECTED] writes:
because if the suggested syntax is used, import directives come in two
flavours: ones that use from to import from a different package and
ones that don't use from and therefore must refer to the current
package.
What is the current package? My
Ian Lynagh wrote:
I think I missed where the plan to use quotes came from. What's the
purpose? Package names already have a well-defined syntax with no spaces
or other confusing characters in them, so why do we need the quotes? Or
is it just so we can have packages with the same name as
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
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
| So instead of just taking this simple solution, the wiki proposal is
instead
| destroying the beauty of the per-package namespace idea by
incorporating
| into it the existing shared namespaces with their attendant problems,
| instead of just letting the existing messy system die a natural death
Simon Marlow wrote:
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
Dimitry Golubovsky wrote:
I'd suggest the following sub-definition for available (other name
could be transient):
A package which is available is not installed at (immediately
known to) a particular developer's system, as opposed to exposed and
hidden which are installed.
When a
Simon Peyton-Jones wrote:
So instead of just taking this simple solution, the wiki proposal is
instead destroying the beauty of the per-package namespace idea by
incorporating into it the existing shared namespaces with their
attendant problems, instead of just letting the existing messy
system
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
be necessary.
2) Exporting modules from other packages.
(This also relates to the Haskell' proposal for qualified exports at
http://hackage.haskell.org/trac/haskell-prime/wiki/ModuleSystem#Permitqualifiedexports )
2a) Exporting the contents of an external module
module Foo
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
Concerning packages, Alex asks:
| We covered this extensively in the Cabal vs Haskell thread starting
| here:
http://www.haskell.org//pipermail/libraries/2005-April/003607.html
|
| You concluded it by saying on April 22:
|
|And this observation points towards a simpler solution: rather than
I'm not sure on which mail of this thread I should append MHO.
What happens if two programmers happen to choose the same package
name? (Prepend the location on the filesystem? ;-)
If something like a package name is introduced I would prefer not
separating package and module name with a .
of .), the entire
namespace of hierarchical modules is supposed to be internal to each
package, and therefore any id of the form A.B.C belongs to this internal
namespace and therefore must refer to an internal module. All modules in
external packages have ids of the form PackageAlias/ModulePath so when
Simon Peyton-Jones wrote:
Simon and I have been thinking about fixing this, and we think we
might actually do so for GHC 6.6. Your message provoked us to write
up the design. It's here
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Feedback welcome
It's worth reading the old threads;
and wouldn't allow the reader of source to know
which packages it's referring to.
I meant the above only in relaiton to modules in other packages. Modules in
the current package would be identified as they are at the moment, without
any package qualification (since only the compiler command line would know
On Mon, Jun 26, 2006 at 04:20:16PM +0100, Brian Hulley wrote:
I don't think this solves the whole problem. Suppose M1 needs to use A.B.C
from P1 *and* A.B.C from P2
For a simple example of a case where this might arise, suppose M1 is the
migration module for data (stored in a database,
Of Brian
| Hulley
| Sent: 25 June 2006 10:16
| To: Haskell-cafe
| Subject: [Haskell-cafe] Packages and modules
|
| Hi -
| At the moment there is a problem in that two packages P and Q could
contain
| the same hierarchical module eg Data.Foo, and the only way for user
code to
| ensure the right
30 matches
Mail list logo
