RE: gnubol: New bison Grammar available (long)

["William M. Klein" <wmklein@ix.netcom.com>]

Boy, do I disagree with this one !!!

To me, if you create an "open COBOL" - that COBOL people can NOT maintain and
enhance, you might as well not do it.  Please, PLEASE, make as much of it in
COBOL as possible.

(As far as "efficiency goes" - you ought to see some of the comparisons that
Fujitsu, Micro Focus and IBM all have on "comparable" C programs when
compared with same-function COBOL programs.  Not only is the COBOL (usually)
MUCH more portable, it is quite often SIGNIFICANTLY better performing.)

Bill Klein
  wmklein <at> ix.netcom.com

> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Saturday, December 25, 1999 11:09 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: New bison Grammar available (long)
>
>
> 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.


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