headers
Simon Peyton-Jones | 3 Jul 2006 18:45
Picon
Favicon
Gravatar

RE: Packages and modules

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
|    invisibly pre-pend the package name, just get the programmer to do
so.
|    So package P exposes a module called P.M and package Q exposes Q.M.
All
|    P's internal modules are called P.something, and similarly for Q.
(We
|    rely on some social mechanism for allocating new package names, as
now.)
|    Now of course you can import P.M and Q.M in a single module.
| 
|    That would be simple.  It might be pretty inconvenient to say
'import
|    Base.Data.List' rather than just 'import Data.List'.  But nothing
forces
|    you to do this -- and indeed we don't do it for the current 'base'
|    package.  The point is that it's an easy way for a package author
to
|    ensure their package won't conflict with others.  If they choose
not to
|    avail themselves of it, it's more likely that their package will be
|    unusable because of accidental name conflicts.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 4 Jul 2006 14:20
Picon
Favicon
Gravatar

RE: [Haskell] problem building syb-generics

[Redirecting to ghc-users]

Matthew

Lexically-scoped type variables are undergoing a slight upheaval in GHC 6.6 that has not quite settled,
and that is what you are running into.

Pattern-bound lexically-scoped type variables are particularly problematic
	f (x::a) = ...

The ones that are totally safe are
	f :: forall a. a->a
	f x = ...
In this, 'a' is in scope in the whole of f's right-hand side.

Maybe you can refactor the code a little to use this?  I'm sorry about this.   We need to get the rules for
lexically scoped type variables nailed down (for Haskell Prime as well as GHC) but it keeps slipping down
my priority list.  It's important but unrewarding!

Simon

| -----Original Message-----
| From: haskell-bounces <at> haskell.org [mailto:haskell-bounces <at> haskell.org] On Behalf Of Matthew Pocock
| Sent: 04 July 2006 12:38
| To: haskell <at> haskell.org
| Subject: [Haskell] problem building syb-generics
| 
| Hi,
| 
| I had some trouble getting syb-generics 2.9 to compile with ghc 6.5 (don't
(Continue reading)

Permalink | Reply | 2 comments |
headers
Brian Hulley | 5 Jul 2006 02:03

Re: Packages and modules

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.  (No guarantee Simon M agrees with what I've
> written... I'm at home this afternoon :-)

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 ("ambiguous import"), or does the current
      package override.

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. There 
would be no such thing as an "exposed" package (afaiu the idea of "exposure" 
is only needed in the context of different packages needing to share the 
same module namespace, which the proposal will hopefully make a thing of the 
past).

Here are some other points:

1) What is the meaning of A.B.C.id ?
I think this would have to refer to id in the module A.B.C in the package 
being compiled. To refer to an id in some other package, you'd have to use 
an alias eg
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Hulley | 5 Jul 2006 03:27

Re: [Haskell-cafe] Re: Packages and modules

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 ("ambiguous import"), or does the current
>      package override.
>
> 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. There would be no such thing as an "exposed" package
> (afaiu the idea of "exposure" is only needed in the context of
> different packages needing to share the same module namespace,
> which the proposal will hopefully make a thing of the past).

I wonder if the wiki question refers to issues of backwards compatibility 
with the existing module system? Ie do you want to keep the existing module 
system with (all exposed) packages sharing the same module space at the same 
time as having a new module system with per-package namespaces?

To allow both to exist simultaneously, I suggest a new keyword (and improved 
syntax below) to mark a per-package namespace import so that existing code 
using "import A.B.C" would still refer to the existing overlapped namespaces 
so that there wouldn't be any problems with backwards compatibility (except 
for the introduction of a new keyword) eg:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Lynagh | 5 Jul 2006 09:30
Picon
Gravatar

Re: Packages and modules

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 (either by email or by adding material to the Wiki)
> >would be welcome.  (No guarantee Simon M agrees with what I've
> >written... I'm at home this afternoon :-)
> 
> 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 ("ambiguous import"), or does the current
>      package override.
> 
> 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.

FWIW this isn't what I actually intended when I was talking about using
"from". I was imagining it would work similar to how "foo" unqualified
can refer to either an imported variable or a variable in the current
package, but we can still qualify "Foo.foo" should we wish to be
explicit. So you can "import" from any package, including the current
one, but qualify "from package import" should you wish to be explicit.

> (modified to use quotes):
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ketil Malde | 5 Jul 2006 09:42
Picon
Picon

Re: Packages and modules

"Brian Hulley" <brianh <at> metamilk.com> 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 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* to specify
package, this makes things a lot less flexible (e.g., moving a module
from one package to another will break code)

Would 'base' be the current package in most cases?  That would
encourage cramming even more stuff into base¹, and I suspect the
overloaded 'base' is half the reason we're discussing all this extra
syntactical baggage.  (E.g. experimenting with a newer version of
Don's FPS, I basically need to replace 'base'.  With the features being
discussed, I could get by rewriting the import statements in all my
fps-using code, which would be an improvement.  It'd be much safer and
better to have a compiler option, of course, but I guess that will
only work for complete packages.)

Anyway (and like you say) I think the workaround using qualification
or hiding is more than sufficient, I consider recycling names from
imported modules for local variables questionable as best, and would
rather it wasn't encouraged. 

> 3) Syntax:
> I liked Ian Lynagh's suggestion of using "from" to start either a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Peyton-Jones | 5 Jul 2006 09:48
Picon
Favicon
Gravatar

RE: Packages and modules

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 so.  It's a helpful process.

One particular point: 

| 2b) Exporting the contents of an external module qualified
| 
|        module Foo
|                 ( qualified module P
|                 ) where

While this might be a good idea, it's an orthogonal one, and the
proposal doesn't tackle it.  One thing at a time!

Simon
Permalink | Reply | 1 comment |
headers
Simon Marlow | 5 Jul 2006 13:40
Picon

Re: Packages and modules

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 keywords?

I think it's non-trivial to embed the syntax of package names into the 
Haskell grammar.  The version part will sometimes lex as a floating 
point literal, for example.  Ugh.  Strings are much easier.

Cheers,
	Simon
Permalink | Reply | 0 comments |
headers
Simon Marlow | 5 Jul 2006 14:14
Picon

Re: Packages and modules

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* to specify
> package, this makes things a lot less flexible (e.g., moving a module
> from one package to another will break code)

Our current plan is a relatively small delta from the current scheme: as 
you say, "from" is only required when there is an ambiguity.

This assumes we keep the current idea of exposed/hidden packages. 
Having a default set of exposed packages is terribly convenient when 
just firing up GHCi, for example.

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 be used only by an explicit "from"
     import (this is rather like a qualified import at the package
     level, and might be useful if you want to use a package with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Niklas Broberg | 5 Jul 2006 14:42
Picon
Gravatar

Re: [Haskell-cafe] Re: Packages and modules

> 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 base?).  Cons: lots more typing, very
>       non-backwards-compatible, still have to list dependencies in
>       .cabal files.
>
> anyone have any more suggestions?  Is there any way to simplify?  I
> rather feel this design is getting a little unwieldy.

Maybe a dumb question, but why not support only exposed and available?
Why have hidden modules that cannot be used, even when the programmer
explicitly asks for them?

/Niklas
Permalink | Reply | 0 comments |

Gmane