Re: gnubol: New bison Grammar available (long)

[RKRayhawk@aol.com]

In a message dated 12/26/99 3:01:35 PM EST, tej@melbpc.org.au writes:

<<   I need to understand the nature of the concern here - it could
 be: ... >>

When I posts that the first thing that needs to be done in
the parser is the nesting of conditional blocks, I am expressing concern about
the compiler construction tools applied to the task of parsing COBOL syntax.

The language has numerous places where we could get what appear to the 
compiler construction tools as ambiguities. The most challenging, in my 
opinion, is the nesting of conditionals. This is because the blocks of code 
that hang on the conditional branches can contain statements of the same form 
as the enclosing statement, thus s/r conflicts will proliferate. 

My point is only that we must prove that the tool, as we would use it, can 
actually parse the language.  In my view it is much more urgent to get nested 
conditional code through an early parser than it is to layout a pathway to 
important and valuable functions that can be possibly coded with mixed 
technology such as some C, some COBOL.  You have eased my concern by stating 
that the parser in its early stage will parse bascially everything, yet your 
exact phrasing
<<
They (all the nucleus grammar in fact) would be parsed but you
would get an error message 'not supported in the core subset used
to build the compiler'.
>>
does not assert that you will actually recurse into the statements within 
blocks on conditional clauses of things like COMPUTE, etc. My point is not 
that we would want the statements in the block to do anything, we just merely 
need to 
prove that the grammar tool we choose, and the way we use it, can see those 
'apparently' ambiguous rules sets and resolve them in a controlled intended 
manner.

The following is not intended to harp on a point, or to make anything out of 
it more than the technical interaction already posted about the shift/reduce 
conflict on the ELSE clauses.  This is not criticism. I emphasize I am just 
trying to say in the following that we need to prove the grammar tool will 
work.  So, if you attempt to resolve s/r conflicts on the alternating 
conditional branches of verbs that sport that topology in the same way that 
you resolve the s/r conflict on ELSE in the grammar you have been so generous 
to post, then you will shift onto the current verb context excessive clauses, 
and never bind them back to outer enclosing verbs.

Yet if you do get a grammar cobled together that proves you can resolve the 
apparent 'ambiguities' with the choosen tool under the choosen strategy, then 
you will already be in the business of seeing the conditional clauses! So why 
plan to emit 'not supported' missives?

Also don't get too mad with me if I haven't been able yet to study your 
conditional clauses per se (and have only looked so far at your IF-THEN-ELSE 
construct, or as you codeded it your IF-THEN-ELSE-ELSE... :-) ) but you have 
done too much work and it is hard to catch up with you. But I will!

Concerning the nesting of EVALUATES and SEARCHES, I would offer this 
expression to you: really, honestly, and sincerely, ... we need to get all of 
it to nest before we deploy any cardinal verb. It is the nesting that counts. 
This is not a selfish expression, I don't want it my way. I want YOU to 
succeed. Don't go way into a grammar that can drive some COBOL encoded 
function subset if you are not sure you can nest everything.

You are on a good path with the precedence 'dummy' tokens, it will mature, it 
will work for much of the challenge.  Complete the top level before you go 
into details.    We need to design before we code.  It is just as valid to 
design with bison and / or C: design does not have to be in English.  But we 
must prove that we have an actual means to nest COBOL constructs before we 
get the contained cardinal verbs to do minor stuff like calculate and move.

The reason this is urgent is that you may find your tool does not work, or 
that your strategy does not work. That will create much extra work later if 
you need to really modify the strategy, or even choose another tool.  For 
example, if bison can not resolve the ambiguities, and PCCTS with predicate 
assisted back tracking can, what will have happened to you the coder of the 
bison effort?

I feel fairly confident that the bison tool will encouter difficulty even 
before we consider transposing the alternating conditionals. If we hope to 
consider transposing conditionals, or consider it our responsibility to 
choose a tool and a strategy that permits transposition for the future GNU 
COBOL contributors who will migrate the tool to COBOL-2000, then I am sure 
bison can not take us to the finished line, IF WE USE OPTIMISTIC HIERARCHIES.


This is a lot of words and there has already been nearly enough on it, but 
the final expression must be that if you choose to shut down the actual 
recurses into blocks hanging on the conditional clauses you are voluntarily 
blinding yourself to the 'apparent' ambiguities that will reveal weakness in 
the tool and/or the way the tool is used.  I do not attack your tool or your 
strategy. I am just saying prove it, or rather asking you to prove it to 
yourself with a full nesting capability. We need to pick the tool first: 
prove your tool will work at the 
highest level, the nesting of statements. 

By the way,  IMHO = In My Humble Opinion (probably somewhat standard), and
IMNSHO - In My Not So Humble Opinion (less common).

Best Wishes

Bob Rayhawk
RKRayhaw@aol.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.