Mikael More writes:
There is no description in the spec of what a library exports if it has no export library declaration, and this could very well be interpreted as something else than that in this case, all of the library's identifiers should be exported.
Rationale: For (library) exports, an export-all by default approach is of value in many incremental development situations.
To give an example, a Tetris game, with rendering, keyboard input, and other libraries. The basic idea is that, as the programmer adds modules to the code project and imports them incrementally into the Scheme environment, it is implicit that every new identifier the programmer defines in a module should be exported to all of its dependencies; The library abstraction is used as a means for subdivision/modularization/separation of code only and the code project is so small that there cannot possibly be any unexpectable identifier/export collision to talk about.
A requirement to explicitly export symbols though, would require the programmer to add this as an extra consideration which is strictly speaking unnecessary, and would provide a clear incentive for the programmer to replace the spec-provided library functionality with a custom one; this would be an involvement of unnecessary complexity, and would also decrease the generality of the spec-provided library functionality so much that a less general name for its |import| form, such as |import-library|, would be really relevant to consider.
I would suggest that the R7RS Library syntax should be intended to deliver for incremental development also, as this appears like the most holistic approach - the Library syntax describe a mechanism for subdivision/modularization of code as it is already, so it would make sense for it to be intended also for this use. Therefore:
Suggestion: I'd suggest that a clarification is added to the spec that all identifiers are exported by default, so that that is the effect absence of an export library declaration has. A library that wants not to export any identifiers specify an export library declaration that lists no libraries, i.e. (export) .
The intention is that if nothing is mentioned in an export library declaration, nothing is exported. Such libraries can be imported solely for their side effects.
Ticket #402 proposed (export-all), though not the interpretation of no export declarations. In WG1Ballot6Results, the WG narrowly decided not to have (export-all) in the small language, on the grounds that it was an additional unnecessary complication, and that it was good discipline to export only what is explicitly mentioned. One member did bring up the idea of exporting all when no declarations are present, and rejected it as violating the Law of Least Astonishment.
In addition, the question was raised whether (export-all) should export what is imported as well as what is defined. There is a use case for both interpretations, analogous to public vs. private inheritance in C++. It's not clear which version this proposal intends, though I'd guess that it's meant to export only what is defined.