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.

To my mind, it would be preferable to follow a coherent way of
declaring sets for both ends: either allow "more liberal" declarations
for both sides, or make it mandatory to specify all the names required
*and* provided.

Or is there a rational for the current, asymmetrical design?

-Matthias

P.S. As a side note from Haskell land: the Haskell module system looks
pretty similar to the current proposal. The Haskell guys went the
"more liberal" way. Sometimes it comes pretty handy to be able to
export all the bindings of a module, or to be able to blindly reexport
imported modules without the need of restating all the things again.
But then, I can also see good arguments for having explicit interfaces
...

P.P.S. There seems to be a small bug in the grammar for export-sets.

--
Matthias Neubauer                                       |
Universität Freiburg, Institut für Informatik           | tel +49 761 203 8060
Georges-Köhler-Allee 79, 79110 Freiburg i. Br., Germany | fax +49 761 203 8052