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:
: For each value of the type of an exportÂrange not smaller than the : leastÂvalue of the exportÂrange and not larger than the greatestÂvalue of : the exportÂrange : : a) the exportÂrange shall be within the scope of a definingÂpoint of an : identifier that is a principal identifier of the value; : : b) the occurrence of the exportÂrange shall constitute the definingÂpoint : of that identifier as a constituentÂidentifier for the region that is : the interface denoted by the identifier of the export part that : contains the exportÂrange; and : : c) the constituentÂidentifier so defined shall denote that value and shall : be designated a principal identifier of that value. : : 6 An exportÂrange serves to export only the principal identifiers of the : values within the specified range; it is essentially a shorthand notation : for listing the principal identifiers for each value. The names that are : specified in the exportÂrange serve only to denote the least and greatest : values and are not themselves exported unless they happen to be the : principal identifiers of those values.
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):
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?
(ISTM they take this effort to facilitate the `..' notation, without introducing implicit exports, or strange situations and ambiguities such as which of possibly several identifiers for a value to export. I don't know if it could have been done any easier, but this question is irrelevant, anyway ...)
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.
- 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?), 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.
[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'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.
Frank