This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.
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