GiladBracha, a primary author of JavaLanguage and now NewSpeak, posted a couple interesting articles in 2009:

* http://gbracha.blogspot.com/2009/06/ban-on-imports.html
* http://gbracha.blogspot.com/2009/07/ban-on-imports-continued.html

The basic argument is that the '''import''' statement (in its various incarnations across most languages) undermines modularity in a ''"deep and insidious"'' way:
* to reuse a module elsewhere, you've got to drag along a whole dependency forest
* to replace dependencies imported by a module, you either replace either the import statements (invasive) or replace the library named by the import (global).
* it creates a global namespace, with all the name collision issues

The articles are clearly written, so I won't repeat the argument here.

The solution Bracha promotes is to:
* parameterize the modules with the dependencies
* handle configuration by passing a big ContextObject around (noting his is a latently typed language)

I can't say I'm fond of explicitly passing around a big ContextObject. I wonder if some support for DynamicScope or ExplicitManagementOfImplicitContext would solve the problem without the hassle. 

---------------

I'm taking this approach with a configuration language I'm developing (based on MarkupLanguageNine), using an ''implicit'' PowerBox instead of an explicit ContextObject (with ExplicitManagementOfImplicitContext, so you can access the powerbox or replace it). The idea is ween the application off the powerbox as the dependencies get deeper. Initially, I was going to use '@import' and '@export' and so on, but on Bracha's advice I'm going to try without imports.

My idea is to have each module to specify which 'service' it provides, allowing for conflicts:
 @module {service=foo, ...}
The idea is that I'll have a directory full of modules. Anyone who asks for '@foo' might select this particular instance. So, rather than importing by name, I'm introducing an intermediate discovery service. If there is more than one module serving 'foo', the choice is made using principles of PolicyInjection and preference heuristics. (The choice will be deterministic and traceable.) Additionally, the module receives whatever parameters. Given:
 @foo {a=1, b=2, c=3} Hello
 World
The module specified with:
 @module {service=foo, args={a=A, b=B, data=D}}
Would receive parameters A=1, B=2, D="Hello\nWorld". The parameter 'c', in this case, is lost.

It wouldn't take much effort to produce a simplified summary of which service each module provides, dependencies, security level, policy and features for PolicyInjection, et cetera so that I don't need to parse every module on startup.