[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
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 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
| 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
Marc Weber wrote:
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
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 "." be
age-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf 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 mod
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, rec
Brian Hulley wrote:
import Gtk/Widget.Button -- instead of grafting
In all cases I think it would be an absolute disaster to allow
modules to be imported without an explicit package id because this
would defeat the whole purpose of having a simple per-package
namespace for modules and wouldn't
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; for
or example
http://www.haskell.org//pipermail/libraries/2005-August/004281.html
But there are many others!
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian
| Hulley
| Sent: 25 June 2006 10:16
| To: Haskell-cafe
| Subject: [Haskell-cafe] Pa
33 matches
Mail list logo
