Re: #include cobol

[David Edelsohn <dje.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

On Mon, Feb 27, 2023 at 10:13 AM James K. Lowden <jklowden@schemamania.org>
wrote:

> To the GCC community and GCC Steering Committee:  Greetings!
>
> We at COBOLworx would like GCC to consider our gcobol front-end for
> inclusion in the GCC project.  We would like to contribute it to the
> GNU Toolchain and have it merged into GCC.
>
> We believe our work is further along than any previous GCC Cobol
> effort.  As you may know, we have been working on the project for over
> a year. Much of the last 9 months have been devoted to testing for
> correctness.  The compiler now passes the core module of the NIST
> CCVS-85 test suite.  Although not ready for production use by any
> means, we expect to pass all relevant aspects of CCVS-85 later this
> year.
>
> Old as it is, Cobol is far from dead.  Estimates run into billions of
> lines written, with millions more added each year, even today.  But --
> because there has never been a free, fully functional,
> source-to-machine compiler for it -- Cobol remains largely locked
> behind expensive, proprietary walls.  GCC can change that.
>
> Cobol also offers a window into what was and might yet be.  In Seibel's
> "Coders at Work", Fran Allen put it this way:
>
>         "There was a debate between Steve Johnson, of Bell Labs, who
> were supporting C, and one of our people, Bill Harrison....  The nubbin
> of the debate was Steve's defense of not having to build optimizers
> anymore because the programmer would take care of it."
>
> and
>
>         "By 1960, we had a long list of amazing languages: Lisp, APL,
> Fortran, COBOL, Algol 60.  These are higher-level than C.  We have
> seriously regressed since C developed."
>
> Modern hardware, and GCC's 100 optimization passes, are evidence Fran
> Allen was right.  Cobol, with its 2 dozen high-level verbs and
> integrated I/O, provides a theoretical opportunity to surpass even C's
> performance in its problem domain, because the compiler has more
> information and more leeway.
>
> As a technical matter, to be sure we are far from achieving that goal.
> It is, as I said, an opportunity.  As we hone our skills, we look
> forward to learning together with others to make it a reality.
>
> Signed,
>
> Marty Heyman, James K. Lowden, Robert Dubner
>

The GCC Steering Committee has approved GCobol as a new front-end for the
GNU Compiler Collection.  Congratulations!

This is the administrative approval.  The initial patches must be
technically approved by a GCC Global Reviewer.  Please coordinate this with
the GCC Global Reviewers and Release Managers for the next or future Stage
1 development cycle.

GCC welcomes support for new languages. COBOL is an important but niche
language in 2023.  GCobol will not be a primary language that is considered
critical for a GCC Release, and if GCobol becomes a maintenance burden, the
GCC SC and community may revisit support for COBOL.

We look forward to COBOL support in a future release of GCC.

Thanks, David