| > Either way, a value constructed by package coll-1.0 will be | > type-incompatible with functions in coll-2.0. The former will have | > original names "coll-1.0:Foo.T" while the latter will have | > "coll-2.0:Foo.T". Trying to provide transparent type upgrade is too | > hard. | that seems resonable. presumably to upgrade a binary package to use a | new library, i simply need to specify a new mapping in its grafting | file, and recompile the package. is that correct? Provided you have source, yes. The idea is that * a bunch of source files (perhaps comprising a package, but perhaps not) depend on one or more packages, and import modules from those packages using ordinary hierarchical module names * when compiling the source files, you graft into the tree some package implementations that match what the source files expect | > Manuel didn't like the fact that an import could mean "relative or | > absolute". But presumably we want to continue to write little programs | > with three modules A, B, Main, and have Main just say 'import A'. So | > presumably the current directory is always implicitly grafted into the | > module hierarchy at the root -- and that is all we need for making | > internal references within a package work out. | am i right in assuming that "current directory" refers to the directory | in which the file being compiled is located? e.g. | if module Main has a declartion "import M" | ghc A/B/Main.hs | will look for "A/B/M.hs" No. Our current idea is that "current directory" means "directory in which you started the compiler. So in your example, "import M" will look for M.hs, not A/B/M.hs. It's too confusing if the modules within a package change the names by which they refer to their siblings! But that's a design choice independent of all the others. Simon