(no subject)

[Simon Marlow]

> > I'd argue that -package is a global option and should stay that way.
> > The only reason you might want to disable -package for certain
> > modules and not others is if you want to do some tricks with module
> > shadowing - and this definitely isn't supported in GHC.  You should
> > pass the same -package to every compilation.
>=20
> Funny, I wasn't actually thinking of hiding -package (effectively
> giving it a scope) when I wrote that. AFAIC, it would be fine for
> GHC to collect all the -package options from the source files it
> wants to compile and then use the same superset of package options
> for all of them (*).

Ok, I see what you mean now.

The real problem is one of modularity:  you use a library which requires
package P, and that requires you to add -package P to the command line
for your program.  You're saying it would be nicer if the library itself
had some way to say that it requires package P.  This isn't so good
either: package P gets added to the command line behind your back, and
it might cause strange problems by polluting the module namespace.

Our current solution is to put the library into a package itself, and
then you can express package dependencies in the package meta-data.
(note that this still suffers from the module namespace pollution
problem).

What we plan to do, however, is for packages with hierarchical libraries
to be "automatic" in the sense that you don't have to say -package P on
the command line to get access to P's modules.  It'll be automatically
included on the import path and linked into the resulting binary if it
is actually used.  Hierarchical modules don't suffer from the module
namespace pollution problem.

> (*) I didn't want to have global supersets of options for language
> extension flags, but those seem to be dynamic anyway, and often,
> their effects spill over to anything wanting to use the modules that
> use language extensions.

language extension flags have a real effect on the source code: they
essentially specify what language the source code is written in (H98,
H98+FFI, H98+FFI+TH, etc.) so IMHO they really belong in the source
code.  Language extensions only spill over into other modules in
well-defined ways: eg. you can define a MPTC in one module, and use its
methods in another module, but you can't write class assertions for that
class in the second module unless you turn on the appropriate extension
flag.  The language extension flags are really about syntax only.

Cheers,
	Simon