(j3.2006) Public Comment J32036

Michael Ingrassia michaeli
Tue Jul 8 20:34:33 EDT 2008

To: J3
From: Michael Ingrassia
Subject: Public Comment J32036
Date: 2008 July 08

Commenter's Subject was "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

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.


More information about the J3 mailing list