Gale Paeper wrote:
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.
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:
: 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).
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).
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.
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.
Frank