[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: subsets
It is not possible to decide what to do without foreknowledge of what end-verbs
are coming:
add a to b
size error
subtract c from d
not size error
display ...
end-add
.
The not size binds to the first add.
add a to b
size error
subtract c from d
not size error
display ...
end-subtract
.
The not size binds to the subtract because the subtract is imperative. We know
this because we know an end-subtract is ahead.
By scanning ahead and changing the verb tokens from "add" to "add-has-end" it
becomes very simple. Even this one becomes simple:
add a to b
size error
subtract c from d
not size error
subtract e from f
not size error
display ...
size error
display
end-subtract
size error <<< error two size error clauses
display ...
.
The grammar is on the lines of
either-or-both:
a
|b
|a b
|b a
;
The code can be in the reductions for a and b so there is no real problem with
this (when there are two options; when there are many as in the data definitions,
you need to manually count them to avoid exponential explosion)..
Apologies for the unholy mash of pccts and bison syntax, hope you get the idea.
Without scanning ahead you are doomed to backtracking, which is a possibly
inefficient but convenient way to look ahead.
I agree that if the programmer does this kind of thing he will confuse himself.
Should we issue a warning and which warning? Perhaps when a [not] exception binds
to anything other than the immediately preceding verb? Or when?
Nesting of conditionals within other verbs.
In IF, you are allowed to have zero or one conditional statement at the end.So:
IF cond
add a to b
add c to d
size error
display ...
.
But I can't find any similar rule for evaluate. There could be such a rule, but
there doesn't seem to be one. I am only up to "go to" in the (nucleus level 2)
grammar so I haven't looked at perform or search etc in detail, but a cursory
glance shows nothing..
Tim Josling
RKRayhawk@aol.com wrote:
> You are trying to break out of the
> difficulty by thinking that the SIZE clause is %right associative, and trying
> to end it or not. It is really the arithmetic statements that are still
> concurrently alive: we end or do not end the arithmetic statement(s).
> ...
> But the problem of the alternate conditionals also fairly strongly recommends
> unconventional use of the tools. Real code has true monsters like my posited
> triple ON SIZE ERROR. We need to handle those, and I think it goes to the
> nieve hierarchy issue.
--
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.