#include cobol

#include cobol

[James K. Lowden]

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

Re: #include cobol

[David Edelsohn]

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