Re: Modules without implementation

Frank Heckenbach wrote:

One of the listed bugs of GPC was "modules without implementation".

Where is the bug listed? It isn't listed under "Known bugs in GPC" at < http://www.gnu-pascal.de/gpc/Known-Bugs.html%3E.

However, if I understand EP correctly, this actually doesn't concern `interface' modules (as in pmodtest.pas without the `implementation' part):

If I understand the comment in pmodtest.pas correctly, EP always requires one and exactly one implementation module to be associated with an interface module. Even if the module-block is empty (except for the required 'end'), there still must exist an implementation module to associate with an interface module. This is what the "shall have exactly one" language in ISO 10206 requires.

: Each identifier having a defining–point as a module–identifier in a : module–heading of a module– declaration containing the interface–directive : interface shall have exactly one of its applied occurrences in a : module–identification of a module–declaration containing the : implementation–directive implementation.

In contrast, the following works in GPC (with an almost empty module-block):

module fjf843m;

export fjf843m = all;

const OK = 'OK';

end;

end.

This is conformant to ISO 10206 requirements for modules (except for the export all extension). It is the module-heading [without the interface-directive] ';' module-block alternative for a module-declaration.

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.

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.

It also seems reasonable to me from the programmer's point of view. When you write a module interface, you know whether there has to be an implementation (namely, if there are any routines in the interface or an initializer or finalizer will be needed) or not (only constants, types and variables without need for initialization/finalization). So it makes sense to specify this explicitly (by writing `interface' or not).

This is pretty much what I called a "pure" interface in the "Combining .o files?" thread. At the time, you didn't see much need for it (or at least not from a unit perspective) or that it had sufficient priority to devote any time on it. However, if your thoughts on it have changed, I think the ISO 10206 suggestion on using an "external" interface-directive is the implementation method to use. For one reason, the syntax location is sufficiently early enough in the parse that you can easily direct the parse to code constructs which don't require any initialization or finalization actions (or at least flag the useage of such constructs as errors). For a second reason, it clearly indicates a programmer's intent that it is strictly an interface-only module without having to deal with the uncertainty of whether the missing 'end' was an inadvertant programmer error or an intentional omission in the deliberate construct of an interface-only module. For another reason, using the ISO 10206 suggested method will hopefully put GPC on the same extensions page as the rare few other ISO 10206 implementors.

Can anyone confirm my interpretation?

For strict ISO 10206 compliance, there is no way to avoid requiring a module-block for a module-heading. ISO 10206 requires the complete specification of a module consisting of a module-heading and a module-block and provides for two alternative forms for the specification.

Gale Paeper gpaeper@empireet.com