On Fri, 2 Dec 2005, Matthias Neubauer wrote:

>It looks to me that the specification of imports and the specification
>of exports follow different philosophies of declaring things.
>
>With imports, some names may get imported implicitly by importing
>other libraries as a whole. If you read an import declaration you
>cannot be sure what exactly gets imported (or, to put it differently,
>what is required by the module.)
>
>With exports, on the other hand, you have to *explicitly* name *all*
>the bindings that get exported. If you look at a module, it is always
>clear what it provides.

Yeah, I saw that too.  Honestly, I'd prefer it were the other way
'round, but I know I'm in the minority with that opinion. Most coders
want a very succinct import directive, because they'll have to write
it many times, and any relevant complex information in the export
directive, because it has to be written once. The laziness-as-virtue
thing means fewer keystrokes wins.

The reason I'd like it the other way round (where you explicitly list
every binding you're importing) is because when I'm debugging, and I
see a mysterious function call that appears to be messing up or does
something I don't understand, it would be nice to be able to just
glance up at the import directive and be able to see where that function
is imported from.

The way it is now, you have to "just know" that foo-incr was defined
and exported in your foo-math library or your foo-rings library, or
your foo-resource library, or wherever.  And IMO, that creates code
that's more opaque than it needs to be and makes it hard for developers
new to any particular project to be useful.

					Bear