Libraries and hierarchies

[Simon Peyton-Jones]

| > 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=20
	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