Frank Heckenbach wrote:
Gale Paeper wrote:
So, as you allude to, there are three kinds of module-declaration forms/patterns. They are:
- module-headings with an interface-directive and no module-block (aka
interface modules).
- module-blocks with a module-identification with
implementation-directive and no module-heading (aka implementation modules).
- module-heading without an interface-directive and a module-block
(aka fully specified ?? modules).
Paragraph 6.11.1 also states:
"There shall be exactly one module-block associated with a module-heading."
From this, it also seem pretty clear that if you have a module-heading
you must have a module-block declared by one of the legal forms to be in compliance with ISO 10206. From the three kinds of module-declaration forms/patterns, there are only two kind combinations which constructs a legal ISO 10206 program-component. One combination is a kind 1 and kind 2 pair. The other combination is a kind 3 by itself.
OK, so can we say what they actually mean to say is something like this -- but they chose not to write it clearly in the BNF, but let the BNF accept more and restrict it again in the text(*)?
module-declaration = `module' identifier interface-directive module-interface | `module' identifier module-interface `;' module-block | module-identification `;' module-block .
Although it doesn't have any syntactic difference, you could expand the third alternative's module-identification into it's component parts for style consistancy, i.e.,:
'module' identifier implementation-directive ';' module-block .
module-interface = [ `(' module-parameter-list `)' ] `;' interface-specification-part import-part { constant-definition-part | type-definition-part | variable-declaration-part | procedure-and-function-heading-part } `end' .
(*) Bad style IMHO. Of course, a BNF will (almost) always accept more than valid programs (undeclared identifiers etc.), but if it's so easy to rewrite it in a stricter way, this should be done. (Otherwise, why not define a BNF that accepts anything? ;-)
I would speculate that perhaps there were more factors involved than just clarity of syntactic contructs. Some of the syntactic forms are arranged to provide nonterminal names for a semantic entities. Perhaps a need to have a tie to the syntax for the semantic entity module-heading was a factor in reducing the clarity of the modified BNF for module-declaration. The prose describing the semantics is pretty dense already; just imagine what it would be like if there wasn't any convenient handles to associate the semantic prose to the syntax.
So, I'll forbid this wrong form again. Now GPC will allow 1., 2., 1. and 2. in one source file, 3. and a "GPC specific form" (which may also be PXSC compatible) without any explicit export part.
Although I think it would be a major headache to implement, I'll note that for full compliance you can't restrict the number of program-components in a source file nor require any ordering other than the parial ordering of the define-before-use 6.2.2.9 requirement. (I'm just noting the requirement and not suggesting that GPC must fully implement the requirement.)
Gale Paeper gpaeper@empirenet.com