Re: Modules without implementation

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