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
| 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
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
In response to Brian and Ian's helpful comments, I've added a bunch more
stuff to our proposal about packages. If I have missed anything, let me
know.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
If you or anyone else thinks the choices made there are poor ones,
continue to say
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
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*
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
Simon Peyton-Jones wrote:
In response to Brian and Ian's helpful comments, I've added a bunch
more stuff to our proposal about packages. If I have missed
anything, let me know.
http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
If you or anyone else thinks the choices made there are poor
| 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 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
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 (either by email or by adding material to the Wiki)
would be welcome.
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
21 matches
Mail list logo
