Re: [open-cobol-list] OpenCOBOL release 1.0

[Tim Josling]

On Sat, 2007-12-29 at 20:20 +0100, Alain wrote:

> As I have read in cobol specifications (from ANSI ?) that you know better
> than me and I cannot retrieve from internet, that a cobol PIC s9(9) cannot
> have a value more than 999,999,999 not enough for 2,147,483,647 I have tried
> with S9(10) COMP and, now, I am trying with PIC S9(9) COMP-5, but not with 
> too much hope that can work well ... 
> After I was trying on an old version of Linux with O-C-0.23.19 + 
> Postgres-7.4, 
> and after O-C-1.0 (new) and if this works, on a new version of Linux with
> O-C-1.0 and Postgres-8.2 ... with the time perhaps I understand what is not
> working. Unfortunally I'm not good enough in C for rewrite the interface for
> cobol to postgres.
> 
> Well, what is the state of Cobol for GCC ?
> 
> Best regards,   

Sorry Alain I misunderstood your posting. You are right, any int32
should fit in 10 digits. I thought you were saying 10 digits should fit
into an int32.

As for COBOL for GCC, I left my job recently and have been working
full-time on COBOL for GCC since 3 December 2007. I plan to work on it
for six months full-time.

I have started from scratch again, and this time I am writing it mostly
in Lisp. The GCC back end interface will be in C and so will the
run-time routines that cannot be written in COBOL.

My reasons for writing in Lisp are

1. I found that coding in C was too slow and tedious and I believe,
based on experiments I have undertaken, that Lisp will be more
productive by a large factor. Thus I should be able to get the compiler
finished a lot more quickly. 

So far I am up to 6,000 lines of code and I am seeing about a 3-fold
reduction in LOC for Lisp versus C. Far fewer ugly bugs also. The
performance is good enough it appears. 

2. As a proof of concept of the above theory about Lisp. I have some
other things I want to do in a very competitive environment and I want
to use the most powerful tools available.

While it seems Python and Ruby are also highly productive, they lack
some of the features of Lisp that I need (macros for example), and
performance cannot be tuned to close to C performance, which you can do
with Lisp.

Regards,
Tim Josling