Re: gnubol: subsets

[Tim E Josling <TIMJOSLING@prodigy.net>]

RKRayhawk@aol.com wrote:

>  What is needed is design work. We need to know the
> total work to be done by the
> preprocessor.

I'm not sure of the value of 'big design up front' in this project. I don't think
any of the grammars so far have plumbed the issues we have to deal with, and BDUF
does not work if you do not know what you are doing, which I do not. Look at the
copy implementations prior to my preprocessor. I learned so much doing the
preprocessor.

I know that btyacc has been successfully used to parse cobol (according to siber
systems). So it seems a likely candidate. It is not as pretty as PCCTS. So my
'design' at this stage is to try and build a parser of the COBOL nucleus using
it, or maybe even using bison. Maybe a few other ugly verbs like read. I am
fumbling ahead in the dark but it is the best I can do.

Someone else is working on the PCCTS grammar. Could they resend their patches to
me because I lost them on the trip over to the USA. I printed some of it out.
Here is one question - "if x next sentence end-if" is not allowed but the grammar
allows this - how was this to be dealt with.

If someone else can come up with a viable complete parser first, good.

I am personally happy that my prepeocessor does the copy/replace/comment-entry
things OK.


>  Many
> valuable annotations
> about challenges ... for example ON SIZE ERROR clauses are left associative
> but they associate in a cascade manner right _through_ intervening arithmetic
> statements back to the highest arithmetic statement that has current scope,
> unless its scope is hidden by something that allows blocks of statements
> which might include a conditional arithmetic statement that would in that
> circumstance be the place to associate the clause. So far no one has named
> the parser tool that will handle that in the proper circumstances, much less
> diagnose erroneous code in a robust manner.
>

Good. Added to it bag of test cases. Give me more 'parse this' cases.

Are you suggesting we need to hand code the whole thing? I think the tools are
quite useful although they will need some help. What are you suggesting - do you
think we have the knowledge to do a whole design?

On the error handling, I am still not convinced of the value of doing elaborate
error messages, beyond what I previously suggested. GCC is very successful but
its error messages are basic.

By the way you are at no risk of offending me. If I were a professional compiler
writer I would not be doing this at home.

Tim Josling


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