Re: gnubol: Cobol internals consideration

[Fred Mobach <fred@mobach.nl>]

"David L. Nicol" wrote:

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

That's not really important as long as we can explain it to Cobol users in a
simple way. And not all of them are that great hackers, so let's try to kepp that
in mind.


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

I don't know about minorities regarding debugging but I'm used to use usufull
debuggers instead of writing a lot of additional code :-). No need to vote.

Regards,

Fred Mobach


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