command-line options become extensional imports

[Ralf Laemmel]

Regarding M. P. Jones proposal 
to move command-line options to the module space,
I would like to reiterate something from an earlier email:

What if you want to express that "overlapping instances" are
fine for a certain class C but not for the rest? Recasted
to the module speak of MPJ, would that require some
parameterisation? I am sure this question makes sense for
several extensions. (A humble solution: One could dedicate
a module to the class C, and then rely on scope rules for modules
regarding the propagation of the 
"import Extension.OverlappingInstances".)

Another issue is of course that this modulish approach, which
I like very much, requires sometimes that an imported extension
X is *reexported* from hacker module H so that some other module
A will also be compiled with the corresponding extensions enabled.
Such invasive, implicit reexport is quite non-standard.

In general, this raises the issue of scopes for such extensions.
For some extensions, they might be *invasive* that they really
require special code for all modules. For some other extension,
there might be a *choice* for applying the extension to the given
module or also all clients transitively or non-transitively.
Aligning these options with the module system, or more precisely
with the existing scope/import/export rules of the module system
seems to be non-convincing to me at this stage.

In fact, finding the ultimate solution would go beyond the scope of
Haskell, it would be an achievement for programming languages
but also software configuration in general.

Regards,
Ralf