Re: [GNU-COBOL] What is the target date?

["Chad Slaughter" <slaught@umr.edu>]

Hello all,
I've been busy and Luara has been out of town so the reply is kinda late.
sorry about that.

Tim Josling wrote :>

[Lines of Code crap d-keyed]

I shouldnt grace this with a response, but ...

Lines of code is a meaningless measure of quantity. 

It says NOTHING about quality or functionality.

[...]
>lines on average. This would still make it a three man year
>project. This

I think this is a major underestimate. I estimated the project on
the order or 8-10 man yrs, (inside joke ahead)
With Luara as the man of course. =)


>Even if there is a holdup looking for a suitable parser, there

Looking for a parser is not a hold up. Its an integral part of the
proejct that relates directly to the projects goals.

Which reminds me: For those that havent looked at teh goals and objects
recently, they can be read under CVS: Cobol/docs.
lots of good stuff in there.

>are lots of
>areas of runtime that could be done in parallel. Eg fast packed
>decimal
>arithmetic, sort/merge, the various file types, report writer
>engine,
>search/search all, string/unstring. All that is needed is to

I suppose I should actually layout the runtime stuff. =)
or more to the point put the runtime layout into electrons

The report writer is unimportant now, but someone can work on it.
Sort/merge have to wait on the file stuff.
The files(seq/relative/indexed) are being developed on top of a
third party product, IronDoc. IronDoc is not quite ready for prime time
so we'll have to wait on this.

the fast decimal will wait until later optimization.

Tables are not important right now.

String/unstring...I am sure someone has a nice library to do it. =)
If not its a ncie little weekedn job.

>define the
>interfaces between the compiler code and someone can get going
>(write the test cases and then start coding ;-)).

Part of the big problem with the runtime stuff, is the unit tests.
My hope would be to have ppl write up test cases, in the form of
cobol snippents, with inputs and outputs, to show the function of
the system. Its then alot easier to hand off the runtime stuff and
say here do this, do that. This has always been part of the problem.
Becasue up to know its been easier to just say"go read the tome"
instead of having to exaplin what is wanted.
And since not everyone has a copy of the std(i am working on fixing that
problem) it makes it hard to contribute.

>In terms of the parser, I am still a little unsure what is the
>show stopper with

its quite simply, One Cobol in BNF, is NOT going to happen.
two, Cobol as it stands is not LALR(1) grammar, nor can it be written
as one, in mine and Laura's estimation.(see below A)
three, using bison would violates a major goal of the project(see below B)

And finally the most compelling reason, =) I said so. *laugsh*

>using bison. Someone made a comment that if RMS told us to use
>bison
>he is an idiot. Perhaps I am an idiot but I can't see any show
>stopper.

Yes, RMS would be an idiot. You probably arent an idiot, you just
dont understand the problem is all.

>Clearly there are elements of cobol where flex/bison need help
>(continuation lines,
>comment lines, debugging lines). These do not seem to be serious
>problems
>though.

no, flex and bison can handle those quite well. They are not the problme.

>There is a more serious problem with array references and
>reference modifications.


>After the parser hits the first "(" it is unclear whether it is
>parsing an array reference
>or a reference modification. No LALR(1) parser, like bison, can
>cope directly with this.
>You need to define a common production array-ref-or-ref-mod, and
>have code
>check that it is valid in context. This is quite feasible.

This is not just a problem with the one simple exampel you chose.
Compared to other probelms, this is nothing. 

>Are there any similar situations, or worse that you are aware of?

Yes, there are. Just pic a verb, any verb(wel almost any =)

Do a little test, try to build a parser ofr the data division only.
Tyr to build a parser for all the math verbs.
Try to parser On size error.

These are the couple that come to my mind. But its best to let laura
give you a complete list.

>If not, why not just go ahead with bison and work around it.

Whynot? Because bison doesnt work. Now if you'd like us to spin our wheels
and develop a prodcut that will never fully be realized, just so you can
use bison, then go ahead. 

If you'd like us to use bison, then develop the following add on tool, 
and we will.
A tool that accepts an EBNF spec for LR(k) grammars outputs a BNF bison
spec with generated action stubs, so we can seperate the grammar from
the assocaiated code. 


>Otherwise we are not going to get
>a compiler built.

The compiler will get built. 

-- 
Chad Slaughter  -- slaught at umr.edu
<PGP public key available upon request>

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.