[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
> "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),
"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
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 the
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 ==>
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 oth
| 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:
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 se
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
pa
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
|
http:/
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 code
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 d
| 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:
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 one
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 "avail
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 fo
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 *hav
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 keyword
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 s
"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"
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
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 ("am
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.
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
24 matches
Mail list logo