[GNU-COBOL] What is the target date?

[Tim Josling <tej@melbpc.org.au>]

Here are some numbers of lines of code for various things:

Gnu C (excluding libc) 959k - includes:
- configurations  187k (machine specific bits)
-  Fortran   193k
- Objective C 26k
 - Test cases 88k

COBCY 12,202

Gnu COBOL V1 6,363
Gnu COBOL V2 1,358

COBG (utilities and part of pre-processor only) 4,500

I would think the effort needed for adding a cobol front end to
GCC
would be similar to the Fortran effort ie 190k.

Clearly a lot of code needs to be written. One person can write
say 100
lines on average. This would still make it a three man year
project. This
means we need lots of parallel work.

Even if there is a holdup looking for a suitable parser, 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
define the
interfaces between the compiler code and someone can get going
(write the test cases and then start coding ;-)).

In terms of the parser, I am still a little unsure what is the
show stopper with
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.

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.

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

consider

move x to a (1 2) (3:4).
move x to a (3:4).
move x to a(1 2).

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.

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

If not, why not just go ahead with bison and work around it.
Otherwise we are not going to get
a compiler built.



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