Libraries and hierarchies

[Simon Marlow]

Iavor Diatchki writes:
> globally unique module names and globally unique package=20
> names seem to=20
> be very similar problems.  i thought the problem we were=20
> trying to solve=20
> was how to present ugly modules names nicely in a (source)=20
> program (this=20
> is what i understood from simon pj's explanatory email a=20
> couple of days=20
> ago, although he didn't use those exact words).  what i mean is:
>=20
> if we have unique package names, then we have unique modules names:
> module A.B in a package P, has the unique name P.A.B.

Yes, that is true.

> the problem as i understood it, was that package names might=20
> be kind of=20
> ugly, and change relatively often (e.g. with new releases, even minor=20
> ones).  so i think simon & simon were suggesting a way to=20
> _distribute_ package source code that might avoid that.
>
> the source code distributed=20
> is "incomplete", as the module names contain "holes" to be filled in=20
> when the package is installed.  i think "grafting" refers to=20
> filling in=20
> the holes.  so i think if we really wanted it, we _could_=20
> think of this as not being a language extension.

Yes, that's more or less it.  Remember that you might not be
distributing source code, it might be binaries.  And also the "holes"
you refer to might have several values once the library is installed.

> having said that, it seems to me that we would always be writing this=20
> "incomplete" haskell (as we always refer to modules by their=20
> "grafted"=20
> names, and not by their real names) and never really see the "real"=20
> program.  so we have basically extended the language, because=20
> after all haskell is what is in the source files.

A library would always be graftable, but in general programs need not
be.  A program would consist of code using absolute module names exactly
as now.

Cheers,
	Simon