08-250r1 To: J3 From: Van Snyder, originally from Michael Ingrassia Subject: Public Comment J32036 Date: 2008 August 14 ---------------------------------------------------------------------- Commenter: James Giles Subject: "Submodules" I understand that when something is issued as a TR it's basically already a part of the standard even though it never went through a public review. However it was the submodule feature that convinced me that public review is just as important for TRs as for whole revised standards. The submodule feature is supposed to have basically three advantages. First, it provides a way of changing code within modules without causing compilation cascades. Second, it provides the ability for vendors to distribute proprietary code without revealing source while still having the advantage of interface checking at compile-time. Third, it allows conceptually nesting of module scopes to any depth. At the time submodules were first proposed, several alter- native ways to address the first two points above were also proposed. Any of these would have been easier to integrate into the standard, easier for programmers to learn, and easier to incorporate into existing programs than submodules. Submodules were essentially the most verbose and least convenient of the ways proposed to deal with those issues. As for the third of the "advantages" of submodules, nesting of scopes to any depth, is something that I believe the language shouldn't support. Once upon a time (in the F8x proposal) internal procedures were permitted to nest to any depth. The F90 standard (I believe correctly) disallowed that. For both practical reasons, and because I've read papers indicating just this point in other languages, I'm convinced that nesting of program units is counterproductive. As I said, I'm aware that submodules are already officially part of the language and nothing I say can reverse that. If submodules were not themselves also allowed to have submodules, I probably would not have made any comment at all - in spite of the verbose way they manage avoidance of compilation cascades. ---------------------------------------------------------------------- J3 response: One of the uses of submodules specified in TR 19767 was to manage and partition large concepts, which would otherwise require large and monolithic modules. Partitioning these modules in the case that their procedures need to share low-level procedures, types, or data entities, is most easily done with at least three levels, with the middle level containing the shared entities. The Ada community has found private child units, the Ada structure equivalent to submodules, to be useful. J3 chooses not to change the submodule feature.