mapping module identifiers to URLs (was RE: [Haskell] URLs in haskell module namespace)

[S. Alexander Jacobson]

My original goal in this thread was to explore a way to map module 
identifiers to the locations of module implementations that 
implementations can retrieve and compile with minimal user 
intervention.  We got sidetracked into grafting, and 
I'd like to return to the original goal.

The big open question is whether that mapping of imported module 
identifiers to retrieval locations is determined per import (like HTML 
links), per module (like HTML base tags), per build (think -i), per 
system (the registry), or centrally/federated like the DNS.

Per system and Centrally/Federated feel like they involve too much 
bureacracy either through a local sysadmin or an IANA like entity 
(currently the libraries mailing list) and they give the programmer 
too little control over which packages they actually want to use.

Per import and per module mapping seem like unjustified maintenance 
headaches absent module identifier relativity (a feature rejected in 
the 2003 grafting thread to which Simon referred [1] though Malcolm 
seems to be backtracking on the issue in in this thread....)

Therefore per build seems like the way to go.  One implementation of 
per build is to extend -i to take URLs but that requires the 
implementation to query every URL on the search path for every import 
and that seems inefficient.  I actually think -i is harmful in general 
because it makes it much harder to track dependencies.

Here is a strawman proposal for replacing -i.

   The compiler/interpreter should accept a "Modules" file that maps
   thid party module identifiers to URLs at which source may be found.
   Here is a strawman file format:

    #moduleId     url(s)
    Foo.Bar.*     http://domain.com/package-v1.0.hkg http://domain.com/package-v2.0.hkg
    Foo.Bar       http://domain2.com/package2.hkg

   The urls on any line enumerate all packages that have compatible
   implementations of the module identified by the module identifier on
   that line.

   Each imported packages may contain at most one Modules file.  The
   implementation attempts to find module URL implementation agreement
   among all imported packages.  If that fails, foreign Modules files
   are interpreted as being included at the line where they were
   imported.  Later URLs for the same moduleId override earlier ones.

   The implementation should give a warning if third party packages
   give conflicting module locations.

Note: Yes, I know about Cabal's Build-Depends, but it doesn't serve 
the need described here.

-Alex-

[1] http://www.haskell.org/pipermail/libraries/2003-September/001457.html

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




On Thu, 24 Mar 2005, Simon Marlow wrote:

> On 23 March 2005 13:11, Malcolm Wallace wrote:
>
>> I think this will be trivially possible once the compilers support
>> multiple versioning of packages.  (Ghc may even support it already.):
>>
>>     {-# OPTIONS -package foo-1.0 #-}
>>     module Old (module Foo) where
>>     import Foo
>>
>>     {-# OPTIONS -package foo-2.2 #-}
>>     module New (module Foo) where
>>     import Foo
>>
>>     module Convert where
>>     import qualified Old
>>     import qualified New
>>     convert (Old.Foo x y) = New.Foo y x
>
> We're not going to support this, at least for the forseeable future.
> It's a pretty big change: every entity in the program becomes
> parameterised by the package name as well as the module name, because
> module names can overlap.
>
> This means a change to the language: there might be multiple types
> called M.T in the program, which are not compatible (they might have
> different representations).  You can't pass a value of type M.T that you
> got from version 1.0 of the package to a function expecting M.T in
> version 2.
>
> This issue came up in the thread about grafting from late 2003 on the
> libraries list (sorry don't have a link to hand).
>
> Cheers,
> 	Simon
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>