Libraries and hierarchies

Simon Marlow
Fri, 8 Aug 2003 13:17:06 +0100

> 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.

No, you just need the text of the modules A.B.C and X.C, same as before.

> > Well, how do you currently understand some program=20
> distributed without
> > the full source for all the libraries it uses?  You need=20
> instructions
> > for where to find those libraries - the only new thing is=20
> that now you
> > also need grafting info.  It's just an extension to the=20
> dependency info
> > that comes with some source code.
> All I need is the documentation of the package, which is an=20
> 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.

Documentation is an important point.  We could have dynamic
documentation that changes with the grafting (Haddock.cgi, anyone?), or
we could use relative module names only in the documentation.  Or we
could just continue to use the default module names.  In practice, I
don't think using the default module names in the documentation will
lead to many difficulties - most of the time, people aren't going to use
any weird local graftings.  The Haddock documentation will probably
including information about where the root of the package is for each
module (it already contains the package name).

> Currently, the legality and meaning of a program is=20
> determined by applying
> the static semantics to the text of the modules comprising=20
> 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.

Think of it like this: the static semantics still takes source text as
input, and the package grafter transforms source text into source text.

It's like CPP: there's a trasnformation which is applied to the source
code before it is compiled.  We don't include the specification of CPP
as part of the language, and we loosely describe CPP source code as
"CPP'd Haskell 98", or sometimes just "Haskell 98" when we're being