Libraries and hierarchies

[Simon Marlow]

Hi Iavor,

> i like this, as i've wanted something like this, and it also seems=20
> simple, although i may be missing something.
> if i download a package, i simply put it on my system somewhere,
> and add this place to the compiler search path (via a flag, or a=20
> compiler configuration flag).  then we can have relative and absolute=20
> imports:  absolute imports would be searched for in the=20
> compiler search=20
> path, while absolute imports will be searched for in the same=20
> directory=20
> as the importing module.  alternatively one could only have=20
> one kind of=20
> import, that is always searched for in the compiler path.  if=20
> i want to=20
> use one version of a library or another, i simply need to adjust the=20
> path when i compile my program.  thus "import A.B" would mean i want=20
> module B that is in a subdirectory A of one of the directories in the=20
> path.  ambiguous imports should be reported as errors.

Since this whole topic is rather hard to think about (I constantly find
myself thinking in circles, anyway), could I ask you to elaborate on the
scheme you had in mind?

   - what do you write in the source?  are any syntax extensions
     required?
      - module header
      - import declarations

   - what is the compiler's strategy for finding imports?  Is it the
     same for source files and interface/object files?

   - what is distributed with a library (a) in source form, (b)
     in binary form?

   - can a compiler produce objects/interfaces that are not fixed
     to a particular absolute module name in the hierarchy? (i.e.
     so that we can do binary distributions of libraries that
     aren't tied to particular absolute module names).
 =20
   - is it possible to have modules that reside at several places
     in the hierarchy simultaneously?

Cheers,
	Simon