Frank Heckenbach wrote:
Gale Paeper wrote:
Note: I haven't fully researched what all the semantic differences are between a principal identifier of value and a non-pricipal identifier. I do note the requirements text takes care to keep the two distinctly separated so I would suppose there is something significant to the difference.
I find this in 6.11.2:
[snip]
So IIUIC, this should work an export `a' and `b' from m2:
module m; export m = (e, a, b); type e = (a, b); end; end.
module m2; export m2 = (a .. b); import m; end; end.
This should also export `a' and `b' from m2 (since `a' is principal, `c' is not):
Frank, this comment doesn't seem to match up with the following example as you have typed it. Is there a typo in "export m2 = (c .. b);"?
If you meant it to be "export m2 = (a .. b);" (note the use of "a" instead of the "c" as you have posted), then your comment makes sense and is correct ( or is at least correct as I understand the requirements in this area).
If you meant exactly what you posted "export m2 = (c .. b);", then your comment makes no sense and is not correct in several ways since "export m2 = (c .. b);" does not lead to a constituent-identifier "a" being exported through interface "m2" and the export-range usage is illegal since the imported constituent-identifier "c" from interface "m" is not a principal identifier of the denoted value.
module m; export m = (e, a, b, a => c); type e = (a, b); end; end.
module m2; export m2 = (c .. b); import m; end; end.
And this should fail because m2 has no principal identifier for the value of `c'.
module m; export m = (e, b, a => c); type e = (a, b); end; end.
module m2; export m2 = (c .. b); import m; end; end.
Might this be a correct interpretation?
Your first and third examples look to me to be the correct interpretation of what should and shouldn't work. I don't know what to make of your second example - either there is a typo in it or you have an incorrect understanding of something.
[snip]
What about the following case? It's also ok, isn't it? (Exporting b = 1.)
module m; export m = (a => b); const a = 1; b = 2; end; end.
Yes, it is ok. Note however that constituent-identifier "b" is not a principal identifier for the constant value "1".
AFAICS, only enum values can have principal identifiers, anyway.
Now that you've pointed it out, I think you're correct that principal identifiers apply only to the constant identifier elements of enumerated types. So, I retract the note part of my comment.
- 6.11.2 informative note 5 states:
"Protected variable-names excepted, a constant-name, type-name, schema-name, variable-name, procedure- name, or function-name that is passed through an interface by a constituent-identifier behaves the same as a constant-name, type-name, schema-name, variable-name, procedure-name, or function-name that does not pass through an interface."
If one presumes the mandatory requirements support this note, then at least the function required identifiers would not be exportable since their constant-expression usage behavior would be different on the import side an the interface from what the usage behavior is on the export side of an interface. The reason being that on the export side the required identifers' defining-point is not contained by the program-block (6.2.2.10) and on the import side the defining point for the imported identifier is contained by the program-block (6.11.3). Thus, 6.3.2 c) would allow usage of required-identifier identified function algorithms on the export side but preclude their usage on the import side since the identifer identifying the function algorithm has a defining-point contained by the program-block.
I don't find a 6.3.2 c) (typo?), ...
It is a typo. It should be 6.8.2 c) which specifies the requirements for function-identifier usage in constant-expressions: ... "An expression shall be designated nonvarying if it does not contain the following" ... "c) an applied occurrence of an identifier as a function-identifier that has a defining-point contained by the program-block or that denotes one of the required functions eof or eoln."
...but so far I tend to agree with your interpretation that:
While the above examples don't definitively rule out all exporting of 6.2.2.10 required-identifiers, they do lend support to John's answer on the question.
The more I try to find a logically consistent reading of the whole text of ISO 10206 in this area, the more I tend to think something was inadvertantly overlooked or missed in specifying the ISO 10206 added mandatory requirements on exportable-name semantics. The missing something would have the effect of something like: "The defining-point of an exportable-name contained by an interface-specification-part shall be contained by the activation of the module-heading containing the interface-specification-part." With something like that, you can get a logically consistent reading of the whole text, still get "normal"/expected usage of the required-identifiers, and avoid the textual inconsistencies and headaches which arise with a 6.2.2.10 required-identifier exporting factor added in the mix.
As the whole text of ISO 10206 is presently written, there seems to be a logic conflict no matter which position you try to take on exporting of 6.2.2.10 required-identifiers. Perhaps I'm missing come critical point, but it seems like if you try to come up with an interpretation of the requirements as written which rules out 6.2.2.10 required-identifier exporting some other requirement doesn't work as it should work and conversely if you try to rule in 6.2.2.10 required-identifier exporting you get logic conflicts with some of the requirements text and informative notes text.
Note: ISO 10206 has the additional semantic requirement on constants, types, variables, etc. "Within an activation of the block, the module-heading, or the module-block, all applied occurrences of that identifier shall denote ..." which isn't in ISO 7185. It has an explicit semantic and syntatic tie to user defined exportable-names and no explicit tie to 6.2.2.10 required-identifiers. But, that requirement just isn't enough by itself to rule out 6.2.2.10 required-identifier exporting and still allow for "normal" usage of those identifiers in other contexts. (The logic chain either rules out using 6.2.2.10 required-identifiers in all contexts or it rules in using 6.2.2.10 required-identifiers in all contexts including export lists. You need some other requirement (or set of requirements) which can be used with that requirement to modify the logic chain in such a manner as to rule out exporting but still allow "normal" usage.)
[snip]
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.)
Currently GPC doesn't allow exporting `Input' and `Output', but I think it's not too difficult to change this. Do we agree that this is correct (with and without renaming)?
Regardless of the decision on 6.2.2.10 required-identifier exporting, I don't think there is anything to question about ISO 10206 requiring support for exporting/importing (along with renaming) the required-identifier variables "input" and "output". 6.11.4.2 explicitly requires required interface-identifiers StandardInput and StandardOutput with respective constituent-identifiers input and output for the interfaces and those constituet-identifiers denote the required textfiles input and output.
Note: I don't think you just can't arbitarily export input and ouput - other conditions (e.g., usage of input/output in the module parameter list or importing the StandardInput and StandardOutput infaces) also need to be satisfied before input and output are exportable. Those other conditions are needed to get the required text files created in a defined state upon main-program-block activation.
So in concrete examples this means that this should work:
module m; export m = (Output); import StandardOutput; end; end.
And this shouldn't:
module m; export m = (Output); end; end.
(I agree.)
I'm in agreement with your should and shouldn't work examples.
I'll note that 6.11.4.2 takes care in specifying the cases when input and output are implicitly accessable for the read/readln/write/writeln file-variable parameter. I think it is specified in such a manner that one doesn't have to worry about providing implicitly accessable file-variable parameter support for a possibly renamed input or output beig imported through any arbitary, non-required interface. If you don't see the required-identifer spelling of "input", "output", "StandardInput" or "StandardOutput" in the specified syntax slots in the module being compiled, there is no implicitly accessable behavior for read/readln/write/writeln and the file-variable parameter must be used in the code.
Concretely, this should not work (with or without the `=> Foo', right?
module m; export m = (Output {=> Foo}); import StandardOutput; end; end.
program p; import m; begin WriteLn end.
Correct, it shouldn't work. Since Program p has neither a program-parameter-list containing an explicit identifier spelling of "output" or an import-part containing the required interface-identifier "StandardOutput", program p has a misssing file-variable parameter error in the procedure-statement "WriteLn". (You need to satisfy one of those conditions to get output implicitly accessable per 6.11.4.2 and therefore meet the 6.10.4 implicitly accessable requirement for omitting the file-variable parameter.)
Gale Paeper gpaeper@empirenet.com