Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
From: Gale Paeper
Subject: Extended Pascal question
Date: 8 Apr 2004, 21:58:13
Frank Heckenbach wrote: > > Quite some time ago, Waldek Hebisch wrote: > > > Gale Paeper wrote: > > > > <snipped general explanations> > > > > I think you missed an important point: interfaces _have to_ brak normal > > textual scope rules. 6.2.2.2 states that inteface is a separate region > > outside of the program text -- in particular inteface is a different > > region then an export list. > > > > Note that 6.11.2 tells us that exportable-name give as defining point in > > the interface. General rules (especially 6.2.2.7) tell us that the > > occurence of exportable-name is simultaneously an applied occurence of > > identifier in export list, which is defined later. > > > > > Frank Heckenbach wrote: > > > > 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. > > > > > > > The same analysis would indicate that > > > > module n; > > export n = (a); > > const a = 1; > > end; > > end. > > > > is illegal. However my reading is that modules `m' and `n' are equivalent. > > Namely, in both cases we have applied occurence of `a' in the export-list, > > reffering to the definition of constant `a' and a defining point of `a' in > > the interface -- since interface and export-list are different regions both > > can coexist. > > With the exception of a minor quibble about equivalence, I agree with Waldek's analysis. The quibble is that the constituent-identifier "a" in interface-region "m" in not completely equivalent to the constituent-identifier "a" in interface-region "n". Constituent-identifier "a" in interface-region "m" is not exported as the principal identifier of the value "1"; whereas, constituent-identifier "a" in interface-region "n" is exported as the principal identifier of the value "1". 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. > > > > 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. > > > > Again legal, defining occurences are in the in the interface, applied > > occurrences are in the export list. > > Just to be sure before I'll change GPC: Gale, do you agree to > Waldek's analyis (i.e., all of my examples should work)? Yes, I agree Waldek's analysis. (Waldek was also correct in pointing out the basic flaw in my export list example reasoning. I had somehow gotten the mistaken notion that there was some sort of program text linkage between the export list text and the interface-region even though 6.2.2.2 explicitly states there is no connection.) > 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". > > > 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. > > There was an answer from John Reagan: "I don't think we intended to > allow that. I'd have to look closer at your investigation to find > the right words." (news:comp.lang.pascal.ansi-iso, subject > "Exporting of predefined identifiers", Feb 2003). I saw John's answer and even with Waldek's later comments, I still think John's thought that exporting of required identifiers wasn't intendend to be allowed is the correct interpretation. However, thoughts and intensions aren't definitive requirements. For an authoritive answer on compliance, the answer has to be derived from the requirments text of ISO 10206 and I haven't seen any good answer which is based on requirements text cites from ISO 10206. After Waldek's comments (which shot down my first stab at a ISO 10206 based answer), I've spent a considerable amount of time on attempting to develop an ISO 10206 based reasoning as to whether required identifiers are exportable or not. I don't think they are but I still don't have a rock solid, ISO 10206 based reason which definitively rules out exporting the 6.2.2.10 required identifiers. I will observe that some of the ISO 10206 text is such that it would be difficult to support the case of exporting the 6.2.2.10 required identifiers. For some examples: 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. 2) In quite a few of the required identifier requirements (mostly in the required procedures requirements), the requirements are stated in terms which allow for no semantic separation between the syntatic spelling of the identifier used to identify the required-identifier-entity/algorithm and the specified spelling of the required-identifier. Some examples: a) 6.7.5.4, "In the statement pack(a,i,z) and in the statement unpack(z,a,i) the following shall hold:..." b) 6.7.5.6, "...the statement bind(f,b) shall ..." There are no modifiying requirements than I can find which would allow for the usage of any other identier than the required-identifiers of "pack", "unpack", and "bind" in the procedure-name syntax slot in a procedure-statement to active the procedure-block of the corresponding required-identifier procedures. Since the requirements are explicitly specified as requiring a procedure-statement with an exact spelling of the procedure-identifier to get the specified algorithmic behavior, putting a different identifier in the procedure-identifier slot is nothing more than undefined behavior. Note: Not all (only some) of the required-identifier entities are specified to require such explicit syntatic forms so the most one can derive from this is that a generalized case of exporting/importing required-identifier entities is most likely not required by ISO 10206. 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. 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. Gale Paeper gpaeper@empirenet.com
Previous mail
Next mail
Unformatted/full headers
Overview 10 days
Subject
Date
Thread
Author
| Author | Subject | Date |
|---|---|---|
| Waldek Hebisch | Extended Pascal question | 30 Nov 2003, 02:29:17 |
| Frank Heckenbach | Extended Pascal question | 7 Apr 2004, 20:54:26 |
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).