Cabal vs Haskell [sic]

[S. Alexander Jacobson]

On Fri, 22 Apr 2005, Simon Peyton-Jones wrote:
> Bottom line: the current story is pretty defensible.  I'm not sure that
> keeping names unique by implicitly using package-ids is worth the
> bother.

If the current Haskell story is that module names are top-level then 
it is incompatible with the current Cabal story.  The current Cabal 
story is that module names are implicitly qualified by package-ids. 
Cabal's build-depends tag says that some set of package names are 
required to interpret enclosed import declarations.  In other words, 
that the import declarations are themselves insufficient to identify 
the external modules required to interpret the enclosed modules.

I strongly prefer the current Haskell story to the current Cabal story 
for reasons enumerated at length in this thread*.  Hierarchical module 
names should need no qualification.  But, they do need some syntax to 
make those names easier on developers.  Here is my suggestion:

   New Syntax                             Translation
   ----------                             -----------
   module Name.Space Foo.M where          module Name.Space.Foo.M where
   import Bing.Baz                        import Name.Space.Bing.Baz
   import HAppS ACID                      import HAppS.ACID
   from HaXml.Text.XML
      import Types                        import HaXML.Text.XML.Types
      import Escape                       import HaXML.Text.XML.Escape
      import Pretty                       import HaXML.Text.XML.Pretty

We also need a standardized way to resolve hierarchical module names 
to interfaces and implementation, but that is a separate topic.

-Alex-

* Quick recap of arguments against Cabal:

   * namespace issues shouldn't be mixed with physical packaging issues
   * dev tools operate on source files/directories not packages
   * Cabal fragility with respect to changes in build-depends tag
   * Cabal fragility with respect to changes in modules of other packages
   * incompatibility between unqualified imports and Cabal versioning

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com









On Sat, 23 Apr 2005, Simon Marlow wrote:

> On 23 April 2005 00:21, ross at soi.city.ac.uk wrote:
>
>> On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote:
>>> 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.
>>
>> This would obscure the hierarchy a bit.  A common current practice is
>> a variant of this: modules either have allocated names or their names
>> have the form
>>
>> 	allocated prefix + proper name + whatever you like
>>
>> e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to
>> work pretty well, and should scale, as long as the proper names are
>> distinct, e.g. package names or otherwise allocated.
>
> Right.  Also, prepending package names to module names to avoid the
> overlap restriction suffers from another difficulty: versioning.  You
> can't combine two versions of a package without including the version
> number in the module names of all the modules in the package.  But then
> you end up with source code that has to be edited when the version of a
> package changes, which is highly undesirable.
>
> IMO, it's a good thing that package names and versions are separate from
> module names.  It means we can (mostly) stick to the original aim of
> using the module hierarchy to reflect functionality, and not clutter it
> up with version numbers and other administravia.
>
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>