Re: Modules without implementation

Frank Heckenbach wrote:

Gale Paeper wrote:

...

Frank Heckenbach wrote:

...

...

What seems to be missing is this variant (no module-block at all), and I'll add it in the next release (that's easy to do):

module fjf843m;

export fjf843m = all;

const OK = 'OK';

end.

I really don't see any need for this variant. It isn't in any way conformant to ISO 10206 requirements and the only "value" of it is to save typing an 'end;'. There are already enough problems with the gaggle of non-compatible, non-standard ISO 7185 based dialect variants so there is no need to create additional problems with non-standard ISO 10206 variants which serves no purpose other than to save typing *four* characters.

I meant that this form *is* according to EP:

Okay, that clarifies that your focus is on ISO 10206 compliance and not on an extension to cover something that is missing from ISO 10206.

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.

...

...

However, AFAICS, EP doesn't require to support `interface' modules without implementation. That's good because GPC has to know when compiling a module whether there will be an implementation part (because it has to create the initializer if (and only if) not).

Actually without extensions, EP strictly disallows 'interface' modules without implementation modules. However, as mentioned a while ago in the "Combining .o files?" thread, ISO 10206 suggests in the note to paragraph 6.1.5 that if one wants to implement an extension which allows for a module-interface without a module body the way to do so is with an 'external' interface-directive.

That's something different (I don't want to go into this again, but as I said, I prefer to specify this on a per routine basis, because it's not generally optimal to have everything or nothing external). Here I'm talking about the cases of interfaces without any routines at all (where there's nothing to be external).

With the follow-up clarification that it is an ISO compliance issue, I agree it is something different.

Not quite the same -- (a) see above, (b) that was about initialization; even pure interface modules may need an initialization in GPC (e.g., if they declare file variables which must be initialized internally). The latter would even apply to external modules (if we ever implement them) because it wouldn't be reasonable to expect the external implementation to call the internal GPC initialization routines.

As already noted, I agree it isn't the same. Although I do have some comments in regards to (b), I think it would probably be best for both our time useages to defer the discussion until such time a pure interface external module extension ever becomes a GPC implementation priority.

Gale Paeper gpaeper@empirenet.com