Libraries and hierarchies

[Ross Paterson]

On Fri, Aug 08, 2003 at 10:21:41AM +0100, Simon Marlow wrote:
> > I may be misunderstanding the transformations you have in 
> > mind, but how
> > do I tell whether A.B.C.f and X.C.f are the same thing?
> 
> Like this:
> 
>   module X.C (module A.B.C) where
>   import A.B.C

My question was: how do I know if the following is legal:

	module Foo (f) where
	import A.B.C (f)
	import X.C (f)

I have to look at the graftings, which are additional to the text.

> > Also, suppose I have the documentation for someone's package, and I'm
> > looking at a program that uses that package, but grafted in at some
> > unknown point in the hierarchy.  How do I understand that program?
> 
> Well, how do you currently understand some program distributed without
> the full source for all the libraries it uses?  You need instructions
> for where to find those libraries - the only new thing is that now you
> also need grafting info.  It's just an extension to the dependency info
> that comes with some source code.

All I need is the documentation of the package, which is an abstraction
of the source text of its modules.  I see an import in the program,
and I look up the module name in the documentation.

Currently, the legality and meaning of a program is determined by applying
the static semantics to the text of the modules comprising the program.
True, this ignores how those modules were found, but it is coherent.
But what is the input to the static semantics under the new scheme?
It seems that it's modules grouped into packages, plus graftings.
Therefore those things are part of the language.