Simon Peyton-Jones | 5 Jul 09:48 2006
Picon

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
Brian Hulley | 5 Jul 15:51 2006

Re: Packages and modules

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 ones,
> continue to say so.  It's a helpful process.

I think the proposed system is too complicated. I'd have thought there were 
some simple aims:

1) Backwards compatibility so existing code doesn't break

2) Allow people to use per-package module namespaces in new code

3) Allow package names to be URLs (Marc Weber's idea 
http://www.haskell.org//pipermail/haskell-cafe/2006-June/016378.html )

And the following possible solutions:

1) The current "import" syntax would refer to shared namespace imports 
(exactly as at present)

2) A new keyword, "use", would indicate use of per-package namespaces

3) Putting the package name in quotes allows more complex package names 
including URLs and packages located in a specific folder etc in future, and 
also makes it clear that the package name is an OS filename (albeit 
(Continue reading)

Simon Peyton-Jones | 5 Jul 15:58 2006
Picon

RE: Packages and modules

| 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
| through the syntactic isolation I proposed.

Brian, 

I think your proposal may be clearer to you than to everyone else.  It's
always hard to reconstruct a detailed proposal by reading long email
threads.

Suggestion: if you feel strongly about this, why not start a Wiki page
(you can link to it from the current one) to describe the design you
propose, at a comparable level of detail?

Incidentally, compatibility with Cabal is a significant goal.

Simon
Malcolm Wallace | 6 Jul 12:03 2006
Picon

Re: Packages and modules

John Meacham <john <at> repetae.net> 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
> packages inside the code will force the creation of yet another level,
> meta-packages, or something. packages should not be a language issue,
> they are an environment one.

I tend to the opposite view.  The meaning of the code should be
expressed in the code itself.  If a module M imports A.B.C, and I can
see two such modules called A.B.C, then the meaning of the code is
ambiguous and ill-defined.  I would rather not have to look elsewhere
(in the build system?  Makefile?  scons?  Cabal file?  DOS batch file?
where?) to find out how to resolve the ambiguity.  Surely the programmer
knew which import was intended.  Is it so difficult to communicate that
information somewhere close to the import itself?

This is the same situation as with compiler flags for language
extensions, foreign imports, and so on.  If a module uses a non-standard
language feature that changes the interpretation of the syntax (e.g.
template haskell), it should say so in the module itself {-# OPTIONS_GHC
-fth #-}, so that I as a human reader know what is going on.  Likewise,
if a foreign import requires a C header file, that should also be
referred to in the FFI decl, not solely as a build option at some
arbitrary distance in the filesystem.

Regards,
    Malcolm
(Continue reading)

Ketil Malde | 6 Jul 13:15 2006
Picon
Picon

Re: Packages and modules

Malcolm Wallace <Malcolm.Wallace <at> cs.york.ac.uk> writes:

> John Meacham <john <at> repetae.net> wrote:

> I tend to the opposite view.  The meaning of the code should be
> expressed in the code itself.  

Sounds like a reasonable principle.

> If a module M imports A.B.C, and I can see two such modules called
> A.B.C, then the meaning of the code is ambiguous and ill-defined.

Surely this depends on the relationship between the two A.B.C., and I think
you make the underlying assumption that they implement different things. 

But I think it's far from uncommon that they are intended to implement
the same funcitonality.  E.g I might be developing my A.B.C to be used
as a replacement for somebody else's A.B.C.  Or perhaps I just want to
check out performance with the latest development version of A.B.C.

Now, to be able to test my version without rewriting all client code,
I suppose I must download and modify the entire package containing
somebody else's A.B.C, and replace A.B.C with my version in it.

I'd much rather do this substitution from the command line; 
    ghc -hide foo -package myfoo ...

Another case that nobody seem to have mentioned, is what happens if I
move a module from one package to another.  Say somebody finds out that
'base' is getting crowded, and wants to move Data.Set to
(Continue reading)

Aaron Denney | 6 Jul 13:32 2006
X-Face
Picon

Re: Packages and modules

On 2006-07-06, Malcolm Wallace <Malcolm.Wallace <at> cs.york.ac.uk> wrote:
> John Meacham <john <at> repetae.net> 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
>> packages inside the code will force the creation of yet another level,
>> meta-packages, or something. packages should not be a language issue,
>> they are an environment one.
>
> I tend to the opposite view.  The meaning of the code should be
> expressed in the code itself.  If a module M imports A.B.C, and I can
> see two such modules called A.B.C, then the meaning of the code is
> ambiguous and ill-defined.  I would rather not have to look elsewhere
> (in the build system?  Makefile?  scons?  Cabal file?  DOS batch file?
> where?) to find out how to resolve the ambiguity.  Surely the programmer
> knew which import was intended.  Is it so difficult to communicate that
> information somewhere close to the import itself?

Then, as John points out, how is package Foo module A.B.C and package
Bar module A.B.C any different than modules Foo.A.B.C and Bar.A.B.C?

(And I agree with Ketil about when it is useful to specify this outside
the source, unlike your flag example.)

--

-- 
Aaron Denney
-><-
(Continue reading)

Malcolm Wallace | 6 Jul 15:51 2006
Picon

Re: Packages and modules

Aaron Denney <wnoise <at> ofb.net> wrote:

> >> Package names should never appear in source files IMHO.
> >
> > I tend to the opposite view.
> 
> Then, as John points out, how is package Foo module A.B.C and package
> Bar module A.B.C any different than modules Foo.A.B.C and Bar.A.B.C?

I have great sympathy with this view - that packages are little
different from a top-level name in the hierarchy.

But Simon PJ's comment (on the wiki page) about the difference between
specifying the _purpose_ of a module in its name, and the _provenance_
of a module in its package identifier, was very convincing.

I have added (yet another) alternative proposal, to the wiki here:
    http://hackage.haskell.org/trac/ghc/wiki/GhcPackagesWithGrafting

The details overlap significantly with the current proposals, but the
main contribution I am trying to bring to the table is the (old but
never implemented) idea of grafting a sub-hierarchy at an arbitrary
location.  This idea has a close relationship with specifying what
package a module should come from.  So, I have tried to combine the two.

Regards,
    Malcolm
Malcolm Wallace | 6 Jul 16:18 2006
Picon

Re: Packages and modules

Ketil Malde <ketil+haskell <at> ii.uib.no> wrote:

> > If a module M imports A.B.C, and I can see two such modules called
> > A.B.C, then the meaning of the code is ambiguous and ill-defined.
> 
> Surely this depends on the relationship between the two A.B.C., and I
> think you make the underlying assumption that they implement different
> things. 

No, I agree that they may be essentially the same module, but one of
them has a bugfix, or a new API call, or something.

> Now, to be able to test my version without rewriting all client code,
> I'd much rather do this substitution from the command line; 
>     ghc -hide foo -package myfoo ...

With the Simons' proposal, and with Brian's, you would need to edit the
source code at all usage positions of "import A.B.C".  I agree that this
is tedious and undesirable.  With my proposal, you could organise your
source code such that only a single file might need to be edited,
replacing say
    module Foo (namespace F) where
    import namespace "foo" as F
with
    module Foo (namespace F) where
    import namespace "myfoo" as F

> Another case that nobody seem to have mentioned, is what happens if I
> move a module from one package to another.  Say somebody finds out
> that 'base' is getting crowded, and wants to move Data.Set to
(Continue reading)

Simon Marlow | 6 Jul 17:22 2006
Picon

Re: Packages and modules

Malcolm Wallace wrote:
> Aaron Denney <wnoise <at> ofb.net> wrote:
> 
> 
>>>>Package names should never appear in source files IMHO.
>>>
>>>I tend to the opposite view.
>>
>>Then, as John points out, how is package Foo module A.B.C and package
>>Bar module A.B.C any different than modules Foo.A.B.C and Bar.A.B.C?
> 
> 
> I have great sympathy with this view - that packages are little
> different from a top-level name in the hierarchy.
> 
> But Simon PJ's comment (on the wiki page) about the difference between
> specifying the _purpose_ of a module in its name, and the _provenance_
> of a module in its package identifier, was very convincing.
> 
> I have added (yet another) alternative proposal, to the wiki here:
>     http://hackage.haskell.org/trac/ghc/wiki/GhcPackagesWithGrafting

I've digested this, and I hope can regurgitate the key points for anyone 
wishing to grasp it quickly.  Please correct me if I get anything wrong:

   - the proposal is to let you specify grafting in the source code

   - you graft a *sub-hierarchy* of a package anywhere in the
     global module namespace (the sub-hiearchy bit is new, I haven't
     seen this proposed before).
(Continue reading)

Simon Marlow | 6 Jul 17:37 2006
Picon

Re: Packages and modules

Malcolm Wallace wrote:

> I tend to the opposite view.  The meaning of the code should be
> expressed in the code itself.  If a module M imports A.B.C, and I can
> see two such modules called A.B.C, then the meaning of the code is
> ambiguous and ill-defined.  I would rather not have to look elsewhere
> (in the build system?  Makefile?  scons?  Cabal file?  DOS batch file?
> where?) to find out how to resolve the ambiguity.  Surely the programmer
> knew which import was intended.  Is it so difficult to communicate that
> information somewhere close to the import itself?

I think this is an oversimplification.  Usually you want your source 
code to be abstract with respect to certain properties of the 
environment: eg. I don't care to include the path to the file containing 
module M in the source code, so that I can move M around if I need to. 
Similarly I don't want to specify the exact version of any module I 
depend on, since the same code probably works with a range of versions. 
  I certainly want to specify that dependency somewhere (but only in one 
place, eg. foo.cabal).

Cheers,
	Simon

Gmane