Frank Heckenbach wrote:
Sometime ago I asked the following questions, but got no replies. What about the EP experts out there? ;-)
I'm not sure about the expert part when it comes to EP import and export requirements. However, after spending quite a bit of time peering at those ISO 10206 section and trying to divine their meaning, I think I can take a stab at reasoning out what may or may not be legal constructs in the import and export areas.
I'll note those sections are pretty obtuse and require very careful, close reading while keeping a close eye on the syntax definitions, another close eye on the notational conventions being used, and a third close eye on the general 6.2.2 requirements.
Some points to understanding the workings of export interface regions are:
Note: With interface qualification, there are some additional fine point details which I haven't included.
1. There are both applied and defining occurrences of identifiers in an export interface region. In the case of renaming, the syntax "slot" positions occupied by the applied occurrence and the defining occurrence are distinctly separate positions. Without renaming, both occurrences occupy and coexist in the same syntax "slot" position.
2. Constituent-identifier defining occurrences are the only type of defining occurrence which can be legally created in an export interface region. The syntax definitions do not allow creation any other type of defining occurrence. Thus, the defining occurrence for any other type must be located in some region outside the export interface region.
3. Exportable-name (i.e., constant-name, type-name, etc.) in the syntax definitions and text is making reference to an applied occurrence. From 2 above, it follows that the corresponding defining occurrences for those applied occurrences must be located outside the export interface region. (For the notational conventions used for applied and defining occurrences, see the 6.2.2.11 NOTES.) Also, from the 6.2.2.9 b) define-before-use rule exception, one sees that those defining occurrences must be located in the module-heading region.
4. The rules of 6.2.2.7 and 6.2.2.8 dictate the legally possible combinations of defining and applied occurrence identifiers allowed in an export interface region. An identifier occurrence which contains a defining-point will by 6.2.2.7 rule out any other defining point occurrance with the same identifier spelling and by 6.2.2.8 rule out any other applied occurrence with the same identifier spelling since by 3 above those applied occurrence will fail the "No occurrence outside that scope shall be an applied occurrence." requirement.
A question to the EP experts. Are these things allowed?
a) module m; export m = (a => a); const a = 1; end; end.
Illegal. The first "a" is a constant-identifier applied occurrence whose defining point location is in a region outside the "m" interface region. The second "a" is a constituent-identifier defining occurrence which by point 4 above makes the first "a" an illegal construct.
b) module m; export m = (a => b, a => c); const a = 1; end; end.
Legal. Both "a"'s are constant-identifier applied occurrences and no defining occurrence of "a" occurs, the "b" is a constituent-identifier defining occurrence and no other "b" occurs, and the "c" is a constituent-identifier defining occurrence and no other "c" occurs. None of the rules mentioned in point 4 are violated and there is no general rule preventing multiple applied occurrences of an identifier in a region (provided 6.2.2.8 isn't violated). Also, I can't find any specific requirement for export interface regions which prevents exporting the same entity multiple times although 6.2.2.7 and 6.2.2.8 requirements dictate that renaming must be used when multiply exporting the same entity in the same interface.
c) module m; export m = (a => b, a); const a = 1; end; end.
Illegal. The first "a" is a constant-identifier applied occurrence whose defining point location is in a region outside the "m" interface region. The second "a" is a constituent-identifier defining occurrance which by point 4 above makes the first "a" an illegal construct.
Likewise for import (assuming m exports a):
Some points to understanding the workings of import interface-specification regions are:
1. Unlike export interface reqions which don't have any enclosed, nested scopes (aside from the interface qualifier quibble), interface-specification regions do enclose other regions for the syntax definition forms with constituent-identifer syntax "slot" positions.
2. In those syntax forms with constituent-identifer regions, each constituent-identifer region has a very narrow scope and each region contains only the defining points for all named interface's constituent-identifers and one specific constituent-identifer applied occurrence (ref. 6.11.3 a)). Thus, all explicitly appearing constituent-identifers have no defining or applied occcurrences in the enclosing interface-specification region. Constituent-identifers as constituent-identifers are confined to constituent-identifer regions which are enclosed by the enclosing interface-specification region. (In import interface-specifications, constituent-identifer scoping works pretty similarly to field-identifier scoping in field-designators, ref. 6.5.3.3)
3. From 2 above and 6.11.3 d) which covers implicitly immported constituent-identifiers, one sees that constituent-identifers as constituent-identifers don't dirty up an interface-specification region with defining or applied constituent-identifer occurrences. An interface-specification region is kept neat and tidy containing only defining occurrences of distinct imported identifiers. Granted some or all of the distinct imported identifiers may have the same spelling as the spelling of a constituent-identifier in the cases of implicitly imported constituent-identifiers and unrenamed explicitly imported constituent-identifiers, but the two identifier bins are isolated from each other.
a) program p; import m (a => a); begin end.
Legal. The first "a" is a constituent-identifer applied occurrence whose defining-point and applied occurrence reside in and are constrained to the narrowly scoped constituent-identifer region which contains just the constituent-identifer "a" occurrence. The second "a" is a distinct imported identifier "a" whose defining point is in the interface-specification region. The 6.2.2.5 scope exclusion rule precludes any 6.2.2.7 and 6.2.2.8 rule violations.
b) program p; import m (a => b, a => c); begin end.
Legal. The first "a" is a constituent-identifer applied occurrence whose defining-point and applied occurrence reside in and are constrained to the narrowly scoped constituent-identifer region which contains just the constituent-identifer "a" occurrence. The second "a" is a constituent-identifer applied occurrence whose defining-point and applied occurrence reside in and are constrained to its own separate, narrowly scoped constituent-identifer region which contains just the second constituent-identifer "a" occurrance. Since the two constituent-identifer regions are distinctly separate regions isolated from each other, no 6.2.2.7 and 6.2.2.8 rule violations can occur.
The "b" and "c" are a distinct imported identifiers whose defining points are in the interface-specification region. There is no requirement that I'm aware of that prevents importing an entity multiple times with unique identifiers for each import. (This seems like a pretty handy feature to have when one needs to repackage interfaces to avoid identifier conflicts.)
c) program p; import m (a => b, a); begin end.
Legal. The first "a" is a constituent-identifer applied occurrence whose defining-point and applied occurrence reside in and are constrained to the narrowly scoped constituent-identifer region which contains just the constituent-identifer "a" occurrence. The second "a" is a constituent-identifer applied occurrence whose defining-point and applied occurrence reside in and are constrained to its own separate, narrowly scoped constituent-identifer region which contains just the second constituent-identifer "a" occurrence. The second "a" is also a distinct imported identifier "a" whose defining point is in the interface-specification region. Since the two constituent-identifer regions are distinctly separate regions and the 6.2.2.5 scope exclusion rule keeps the two constituent-identifer region "a"'s from clashing with the distinct imported identifier "a"in the interface-specification region, there aren't any 6.2.2.7 and 6.2.2.8 rule violations.
Hopefully, I haven't made any mistakes in interpretting ISO 10206 requirements in these areas and that my explanations will help in understanding what may or may not be legal import and export constructs.
P.S. Frank, quite some time ago in the comp.lang.pascal.ansi-iso newsgroup you asked a question about exporting with possibly renaming predefined/required identifiers and I don't think you every got an ISO 10206 based answer. The 6.2.2.9 b) define-before-use rule exception I mentioned in export interface regions point 3 which requires exportable-names to have module-heading region defining-points in conjunction with 6.2.2.10 which conceptually places all but four of the required identifiers in a region enclosing the program is what precludes exporting with possibly renaming all but two of the required identifiers.
The two exceptions are input and output. For those two, defining points are created in the module-heading region either with the useage as a module parameter or with importing the required interfaces StandardInput and StandardOutput into the module-heading. (StandardInput and StandardOutput are the other two of the four required identifiers not covered by 6.2.2.10 but interface identifiers aren't exportable-names and thus cannot be renamed.)
Gale Paeper gpaeper@empirenet.com