In looking at the current structure definition (see the STRUCT stage
in pipenew.pdf), and after a gentle nudge or two, I'm beginning to see
a number of issues:
1. The definition of a top-level structure and an imbedded structure
are not parallel. (:<id> vs STRUCT <id>).
2. There is no way to signal the end of an overlaid structure. The
end of a top-level structure is the : that starts off the next level-1
structure.
3. There is no provision for arrays. (<inputRange> needs to
understand arrays too.)
4. If you have arrays, the bounds should be specifiable as a manifest
constant that can be used in a SPEC while clause to iterate over the
array.
I think this can be accomplished with backwards-compatible extensions.
In the following, "{" etc means the literal left brace rather than
opening a list of alternatives, as it would mean without the quotes.
Likewise "[" means a literal left bracket rather than something
optional.
(If you're reading this in EBCDIC, the square brackets [] and curly
braces {} may be messed up; my apologies, but his is outside my
control.)
<structure> ::= STRUCTure <id> [ <dimension> ] [ <constlist> ] "{"
<member>* "}"
That is, the end of a structure is indicated by the } closing the list
of members. To be backwards compatible, the {}s are optional, though
this is not shown here. (Of course, if you omit the { you cannot
specify the end of the structure other than by a colon).
A structure that is used in an array cannot contain a variable-length
member (Length *) nor can it contain word-style members.
As the number of members is optional, you will be able to define a
structure that contains only manifest constants.
<dimension> ::= "[" <constant> "]"
Very much in the C tradition.
<constlist> :: <manifest constant>
| <constlist> , <manifest constant>
<manifest constant> ::= <constid> = <number>
Manifest constants and member names in a particular structure are in
the same name space and mutually exclusive.
The scope of a manifest constant is the structure that contains it.
Manifest constants in dimensions are dereferenced when STRUCT
processes the structure declaration. By default, they are resolved
from the list of manifest constants in the structure definition, but
they can also be fully qualified.
<constant> ::= <idlist> | <number>
A member can also be an array:
<member> ::= <id> [ <dimension> ] [ <type> ] ...
To reference a member of an array in an <inputRange> in general:
Member <idlist> [ <dimension> ]
In addition, SPEC scans for an expression within the brackets.
I also think that there needs to be a way to specify a fully qualified
identifier, so it can override the current QUALIFYer, but using a
leading dot is so much contrary to the SFS way of naming directories
that I hesitate to use this subterfuge. Two dots may work. Any
suggestions?
The downside to this is the introduction of the brackets and braces,
which are not invariant code points the EBCDIC code pages. CMS/TSO
Pipelines uses code page 1047 (which is identical to 37 for this) so
the Americans can go back to sleep.
Is there popular demand for something like the C++ trigraphs? (??(
and ??< for [ and {, respectively.)
Anything else I should consider?
j.
