Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Gale Paeper
Subject: Extended Pascal question
Date: 16 Apr 2004, 23:16:19
Second try. For some reason the first never made it to the GPC mailing
list server.
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.
> > 1) 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
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.
Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.
This page was created by Crystal 0.999 (Linux 2.4.27/i686).