Re: gnubol: Re: Magic tokens

[Tim Josling <TIMJOSLING@prodigy.net>]

Bill,

This is my fault so let me explain. It is a long way down a dead end street.

In this discussion I am assuming that nested conditionals are invalid, but the
problem also exists if they are supposed to be valid Either way you have to parse
as though nested conditionals are valid (just sometimes you need to mark them
invalid later - see further down). Nested IFs are valid and that is not a problem
because else only gets used in one place - the meaning of this will become
apparent later.

There is a rule that a conditional phrase matches to the previous verb which
could match with it, and which has not used up that conditional phrase. The
indenting explains the matching as I understand it. I am just talking about
matching, note, most of these examples are erroneous IMO. #=fullstop

add a to b
       size error
              add c to d  <<< error nested conditional
                     not size error
                           display
#

add a to b
       size error
           add c to d
                  size error
           end-add
       not size error  <<< can't match 2nd add due to end-add closing it out
             display
#

The problem is how to detect the error in the first case. A simplistic grammar
says an add statement can consist of an add statement plus either or both of the
[not] size error clauses, either of which can include imperative statements. Plug
this simplistic grammar into bison and it says:

add a to b
       size error
              add c to d
       not size error
              display
#

The 2nd add terminates with the 'not' because we know 'not' can't exist within
the 2nd add which is an imerative statement, and the imperative form of add can't
have the ' [not] size'

The only little problem here is that we are parsing an error as correct, and we
are parsing it wrong. The not size will operate on the wrong 'add'.

The solution I devised is that I pretend that nested conditionals are valid and
then once I have parsed the structure, I error out the nested conditionals. This
enables me to detect them and flag them as errors, while parsing correct code
correctly.

So I defined them this way and found a problem. Right near the end when I got to
'search'.

Parse this:

EVALUATE my-ws-hope-its-not-a-reserved-word-case1
    WHEN 1
           SEARCH b VARYING ix
                   WHEN b (ix) = "free"
                                display "free"
                    WHEN <<< who owns this WHEN??? >>> b (ix) = "used"
                                display "used"
     WHEN 2 <<< first search ends just before this when >>>
           SEARCH b VARYING ix
                   WHEN b (ix) = "free"
                                display "almost free"
                    WHEN b (ix) = "used"
                                display "almost used"
#

At the question marks, it is hard to tell whether the WHEN is a when from the
search or a when from the evaluate. Bison can only look one token ahead, and it
needs to know when it hits the third WHEN that the SEARCH is complete. But it
can't know. Other parser tools use trial parses or backtracking to get over this.
It may not even be possible to tell -  I am not entirely convinced it is soluble
at all. Some of these constructs may be truly ambiguous.

By what I think is a suspiciously fortunate NON-coincidence, the standard comes
to the rescue. Most conditional verbs are conditional because of two things

a) they have some special clause like 'on error' or 'on overflow'
b) they have no end-verb to finish them off.

However SEARCH and EVALUATE are always conditional unless they terminate with
end-verb. No special clauses are needed. The implication is that I don't need to
trial parse conditional SEARCH and EVALUATE within conditional statements.

So I can change the grammar so that only search and evaluate can be included
within another conditional verb provided they end with end-verb. This requires a
fairly simple scan ahead (using a stack) to change the SEARCH to a magic token
SEARCH_HAS_END and the same for EVALUATE.

The end-verb makes it unambiguous who owns the WHEN.

Hope this helps.

Tim Josling

"William M. Klein" wrote:

> > -----Original Message-----
>   <snipped>
> > Yet the standards question about S in E, and E in S need to be
> > addressed too.
> >
> > Bob Rayhawk
>
> Can you explain to me exactly what the question is concerning this (or give
> me a code example that you have a question about)?  I think that given the
> strict "imperative" enforcement rule, I don't know of any problem with SEARCH
> contained in or containing EVALUATE.  (As I indicated in a previous note,
> there is a rule/question about SEARCH and "implicitly terminated"
> conditionals BUT that only applies when the SEARCH is in an IF/ELSE construct
> (where a conditional is allowed).
>
> Bill Klein
>   wmklein <at> ix.netcom.com




--
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.