Gale Paeper wrote:
If I'm reading ISO 10206 correctly, it isn't a legal code construct.
: programÂcomponent = mainÂprogramÂdeclaration `.' : | moduleÂdeclaration `.' . : moduleÂdeclaration = moduleÂheading [ `;' moduleÂblock ] : | moduleÂidentification `;' moduleÂblock . : moduleÂheading = `module' identifier [ interfaceÂdirective ] : [ `(' moduleÂparameterÂlist `)' ] `;' : interfaceÂspecificationÂpart : importÂpart : { constantÂdefinitionÂpart : | typeÂdefinitionÂpart : | variableÂdeclarationÂpart : | procedureÂandÂfunctionÂheadingÂpart } : `end' .
Note the optional module-block in the first form of module-declaration. So IIUIC, there are 3 kinds of "module components": module headings with `interface' (aka interface modules), module headings without `interface' and module identifications (aka implementation modules).
I think the point of misunderstanding is with "module headings without `interface'". For this case, EP requires a requires a module-block to follow the module-heading.
I think the relevant text from paragraph 6.11.1 is:
"An interface-directive shall occur in a module-heading of a module-declaration if and only if a module-block does not occur in the module-declaration."
From this, it seems pretty clear that if you don't have a module-block in the module-declaration form/pattern you must have an interface-directive. Conversely, if you do have a module-block in the form/pattern you cannot have an interface-directive. Therefore, the missing "(no module-block at all)" variant under discussion cannot be a ISO 10206 legal variant since no module-block dictates the useage of an interface directive in the module-heading.
So, as you allude to, there are three kinds of module-declaration forms/patterns. They are:
1. module-headings with an interface-directive and no module-block (aka interface modules).
2. module-blocks with a module-identification with implementation-directive and no module-heading (aka implementation modules).
3. 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 . 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? ;-) 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. Frank -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707