Re: gnubol: Cobol internals consideration

["David L. Nicol" <david@kasey.umkc.edu>]

Glen Colbert wrote:
> [quoted text below]

I like the idea of defining the whole storage area as a big C data
structure of some kind and then manipulating it just like COBOL does.

But if, as you say,

> Cobol was never meant to be a programmer environment,

Why do we care 

> if GNUcobol is going to interface into the standard debugging tools as Cobol
> (and not as 'C')

or not?

> Writing a 'virtual machine' in 'C' provides all of the portability of using
> gcc as an intermediate compiler, while allowing for full integration with
> standard debugging tools at a later date.  Taking the Cobol to 'C' approach
> will require a complete re-engineering later in the project.

If the symbol names for intermediate terms are inherited, the C
debugging
tools will make sense.  I dunno, I always write code to produce
additional
outputs instead of fussing with debuggers, but I do not know how small
of a minority that places me in.


______________________________________________________________
                      David Nicol 816.235.1187 nicold@umkc.edu
      End Daylight Savings Time in the year 2000 --just say NO

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