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@haskell.org http://www.haskell.org/mailman/listinfo/haskell