[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: problem 9; data list collisions.
There has been some interaction on the INSPECT verb. A recent post is quoted
below.
I think I knwo what we can do about this problem. Basically, the pattern
looks roughly like this;
VERB
repeating-major-phrase :
one-data-item more-phrasing repeating-data-LIST
The problem being that as the major phrase is about to repeat, the
repeating-data-LIST
at the end would correspond to a grammar rule that will gobble up the next
one-data-item, pacman-like, and make it impossible for the next major-phrase
to get started right.
(As an aside, the problem actually does not occur when the BEFORE/AFTER
clause is
added to the whole structure, as it should not look for a list, but only one
item. But see below).
A solution is to FRAGMENT the gramar rules, but this fragmentation involves
distinguishing, the first occurence from the subsequent occurrences. The
rules would look roughly like this;
VERB
major-phrase :
one-data-item more-phrasing repeating-data-LIST
optional ! repeating-major-phrase-FRAGMENT :
more-phrasing repeating-data-LIST
This is what you would call a trick! And it is a trick trick if I do say so
myself. The objective here is to get the tool to stop bellyaching about
conflicts.
The conflicts occur from the fact that there is a real ambiguity for any next
data item on the repeating-data-LIST; is a next item another for the list or
does it belong to the next major-phrase repetition.
This problem can be generalized, and it is probably useful to generalize it;
we have this ambiguity whenever two data lists can occur adjacent to one
another in the grammar. (When one or both of those list are 'supposed' to be
a single element, we have the special cases of this problem). The INSPECT
TALLYING 'tallying field list' can collide with the 'count field (list of
one)'.
Actually, the BEFORE/AFTER tally 'bounding filed (list of one)' can also
collide with the 'count field (list of one)'. But it is easy to extinguish
the flames that causes in the grammar.
So a fragmentation of the nature sketched above leaves the second and
subsequent repetitions of the TALLYING clause object with out 'count field
(list of one)'. The solution for that is to borrow it back in the action
code. When one of the 'subseqent' rules reduces, it shuld know that the
preceding rule had a list, it can just rob the last item. (Note in passing
that that list might have an error, of only one item, which needs to be
caught before the robbery, or afterwards - semantics perhaps detecting that
the 'tallying field list' got reduced to zero).
This borrow back may require a delay in the emissions from syntax to
semantics. I assume that comments from the bison afficionado indicate that he
is not much concerned about late release to semantics, as it seems like he
tentatively plans to hold every thing in ram on AST and or linked lists. The
PCCTS champion may need to heed this problem, and note the small issue about
timing implied. If there too we have a plan for growing large ASTs (etc) then
early 'release' is probably not a problem there either. But LL tools tend to
lead to early reductions, should we decide to consider an approach like the
above, it needs to be tuned to the tool and the exact strategy of building
the tree so that the 'borrow back' happens early enough.
While we are thinking about it, for LL, we could do this is a transverse
manner:
VERB
major-phrase :
one-data-item more-phrasing
optional ! repeating-major-phrase-FRAGMENT :
repeating-data-LIST more-phrasing
mandatory ! ending of one more :
repeating-data-LIST
Here we would need an unsteal of the whole front of the list, to glue it to
the preceeding repetition, and a retension of the last item on the -LIST as
being the true begining of the next repetition. This latter approach may be
better for both LL and LR.
For both approaches the last -LIST is always left intact.
(This -FRAGMENT approach shifts responsibilities from the grammar rules to
the actions, and possibly also some to semantics).
The discourse here about generalization of this issue, is intended to lay
some ground work for _possibly_ discussing application of it to other areas.
The STRING and the UNSTRING constructs hae some repeating phrases that
present the possiblity of collisions. But in these cases the stretch of code
looks something like this;
one-data-item blah blah blah one-data-item
one-data-item blah blah blah one-data-item
one-data-item blah blah blah one-data-item
If we apply the rules we should, then simple data references can be made to
reduce right away, and not collided with the next data-item which starts a
next repetition. But we may wish to look at this differently. A _possible_
error production in all locations where a single item should be specified is
to go ahead and look for two or more, just to keep the parser on its feet.
So substitute a list at either end, or at both ends of these repeating
phrasings, and you get the smoke out of the tools ears.
In these situations, if we choose to consider encoding list rules, we will
likely need to use some kind of a -FRAGMENT rule pattern, and 'borrow backs'
or 'unsteals'.
This is not really far fetched, although as we watch the stingy clock on the
wall refuse everyday to yield more than twenty-four units it is currently
enough just to get obvious rules into place and try to find our way to
executables. There is a point at which we will come back to this, so it
seems useful to not only try to express a specific solution for the INSPECT
TALLYING clause, but for the general problem. Out experience with INSPECT
may give us confidence to try it elsewhere.
There are several places where coding data-lists rather than 'expected'
single items will recommend itself. The arithmetic verbs are quite variable
in the way they sometimes allow lists, and sometimes require single data
items.
The chance of coding mistakes here is high. I think the criteria Tim
suggested for error productions, is a) we know what the error will be, and b)
we can surmise that it would be common enough to justify the effort.
To code a data-item-LIST where only a single data-item is expected, requires
code in the actions to check the count or a switch that says single/multiple.
(potentially in quite a few places). And it requires some kind of a
commutable error flag system, so that errors can percolate up the rule
hierarchy.
Anyway, back to the mainline, INSPECT. The only other verbs that appear to
have the minor repeating pattern of data-LISTs inside of a major clause
repetition, that can generate a list collision are STRING and UNSTRING. If
anyone can see others, please point them out, for further study in the
context of the possible applicability of -FRAGMENT rule techniques.
Best Wishes
Bob Rayhawk
RKRayhawk@aol.com
.
In a message dated 12/27/99 10:37:47 AM EST, migrate@tiac.net writes:
<< At 04:10 AM 12/27/99 EST, RKRayhawk@aol.com wrote:
>In a message dated 12/27/99 1:41:34 AM EST, tej@melbpc.org.au writes:
>
><<
> INSPECT a tallying x for all y ZZZ.
> INSPECT a tallying X for all y ZZZ for leading z.
>
> So ZZZ could be something else you are counting or something you
> are putting the next count into. I think.
>
> Take out the magic tokens and see the conflicts, if you have
> bison which I think you said you do.
> >>
>
>Well I trust you are correct. I have bison and I can not believe how quiet
it
>is when it scans your rules. Positively erie!
>
>
>But my COBOL manual does not say that you can have a list where your
example
>implies that you think you can:
>
> INSPECT a tallying x for all y ZZZ.
I checked the COBOL standard, and it allows a list as above. The
BEFORE/AFTER phrase is conditional, so the repeatition on the outer braces
applys to identifier-3/literal-1
>>
--
This message was sent through the gnu-cobol mailing list. To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body. For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.