Re: gnubol: New bison Grammar available (long)

[RKRayhawk@aol.com]

In a message dated 12/22/99 6:19:34 PM EST, tej@melbpc.org.au writes:

<< 
 Example - working-storage ( I am assuming COBOL is the lingua
 franca of the list).
 >>

And then posts some explanations in COBOL.

He also makes this comment:
<<
Compiler subset. The subset of the language that can be used in
the runtime of the compiler and in compiling the rest of the
language will be a limited subset.
>>

The basic idea here has been suggested before; that we somehow get COBOL up a 
little, and use it to write the rest of COBOL. IMHO that is a mistake. The 
one thing that is running very short of supply these days is COBOL 
programmers.  COBOL programmers who enjoy compiler technology are rare 
indeed. It is not that difficult to find C programmers who enjoy compiler 
technology.

Simply coding in two languages, C and COBOL, makes the project harder to 
complete and maintain. We should code the compiler and supporting routines 
with one discipline, C.

There is an efficiency issue here, also (although I know  I know I know, you 
all don't believe me).  But just try to believe me. Some COBOL systems are 
quite large. This is a fine point but it really will make or break some 
decision to use this tool. The COBOL programs themselves do not have to be 
efficient (although the more efficient the better), but the development tools 
must be efficient. The COBOL subset components will not be efficient. We are 
in a deep trough anyway since we plan to go through GNU C at the back end.

Anyway, IMHO, mixing language tools is a mistake. It makes it much harder to 
find resources.  Much of the back-end can be written in C. Why put any of 
those functions out of reach of such a large resource pool by coding it in 
COBOL.  COBOL is great but the schools are not great with COBOL. It is hard 
to find COBOL programmers.

Bootstrapping a compiler into existance by implementing increasingly 
impressive subsets is very heroic. But frankly I do not believe it to be 
attractive to the users we are after who are very conservative, non 
techinical, utterly business oriented folk. A mixed tool foundation looks 
ill-conceived to them, I think. A mixed tool foundation also is very 
vulnerable at redeploy stages.

I think a different subset approach is appropriate.  We should go after the 
subset that maps easily to existing native C functionality: such as, 
int==BINARY, char c[n]== PIC X(n), 
printf==DISPLAY. We can get to proof of concept early and easily without 
bootstrap gymnastics.

We need a significant amount of talent that can see COBOL and C, there is no 
way around that. 

I frankly believe that if we had a basic BINARY/PIC X(n) subset we could use 
COBOL skills in testing.  That valuable contribution could easily take enough 
time for us to deploy more C based code functionality to be tested with 
additional COBOL source code.

The testing requirements of this project are atleast as large as the 
available talent. Looked at from that perspective we have no spare resources 
for coding the grammar or semantics in any language.

If semantics were designed, we could start to code it now. We really only 
need the design, we do not need the parser to be complete to start on 
semantics.

Best Wishes
Bob Rayhawk
RKRayhawk@aol.com


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