[open-cobol-list] future Developments, Brain Storming

[Patrick]

Hi Vince, Hi John

I thought it might be good to start a new thread to discuss this, rather 
then continue on with the 60 character identifier thread.

So I would like to offer a public apology to Vince. I had sited a book 
that mentioned the 60 character limit as standard in 2002. However the 
book is wrong it's not in there.

It sounds like there were quite a few people upset with Cobol 85 
revision and there would surely be others who would be or are, upset 
with the 2002 revision. I am worried about how we can make everyone happy.

I am very interested in contributing code to the compiler. I don't like 
C that much and I don't think I am great with it but I have read a bit 
about compilers and I feel like I can take all my C studying and turn it 
into good code if there are others to review it for the first few 
months. Again I have to learn Cobol properly first, so I am 3-6 months away.

So here are some ramblings...

There is a guy on the google comp.lang.cobol list that thinks Cobol is 
so bad and he "can do anything now" because he is programming in C#. I 
spent about 70-100 hours trying to decide on what language I should 
learn first back several years ago. I started with Python and thought I 
had to become a "python programmer". I soon learned that learning 
another programming language was not as hard as learning an unrelated 
spoken language, like Malagasy after learning Farsi. Aside from Assembly 
most common languages have a great deal in common and I have tinkered 
with about 20 in the past 7 or 8 years now.

So my point is, that I like that OC generates C as it is very easy to 
work with other languages this way. I think OC could offer a lot as 
library code to many projects written in other languages particularly if 
they want to use flat files.

Chris gave me a helpful tip with his naming convention scheme and I am 
sure it will work but I would like to use long descriptive names too and 
the 60 character identifier limit looks like a better fit with what I am 
envisioning.

I am not sure I personally need full blown OO but others might. I figure 
I can deal with errors by coding lots of validation code before a 
procedure call but other people might like exceptions.

I don't like compiler directives but other people clearly do.

I don't like complex user defined types but clearly other do and they 
are powerful.

I do like the idea of user defined functions. I am interested in using 
Cobol well outside of it's traditional domain of business logic and it 
is going to be tedious calling everything I want via procedures.

So here are some rough ideas...

Ada's way of interacting with Cobol, ASM, C and C++ is through the use 
of spec files. Ada body files contain most of the Ada code but the spec 
files define an interface to code written in other languages and 
actually to Ada body files too.

I am wondering if some sort of separate file plan would work well for 
us. Most user defined functions would likely be written in C. I wonder 
if some sort of Cobol spec file could be used to define the way that the 
C functions would be called and how they would be named in Cobol. For 
instance FOO-POO is not a valid identifier in C but FOO_POO is. Function 
Dozen_Eggs in C will take a large integer range but we want it to take 
only 1-12, the Cobol spec file could define this. In addition those that 
do not want the language revisions could easily quarantine code as it 
would separate from the main Cobol code or at the very least they could 
read one file and see what was added to the language.

Another thing. If I want to use GTK, Curl or whatever C library I need 
to write a C interface to the existing C code, foo() becomes OC_foo or 
similar. If I could just link in a header file at compile time and then 
call existing functions without wrapper code that would be so much 
easier. I wonder if an extension to libcob could be added to make this 
possible if the spec file idea is stupid.

Could compiler directives also be put in spec files? I find that they 
make C code hard to read but they are certainly useful.

I am not crazy about C++ but it would make implementing OO easier. Could 
the generated code be wrapped in extern "C" statements to make the 
resulting code easy to use with other languages?

Another thing. Should we fork the project so that there is a Cobol 85+ 
version(has a little 2002) and have a separate Cobol 2002 version? They 
could still share code.


Unicode support would be good for the language too but it looks like 
there might be some issues with ncurses according to what I read in the 
forums.

This email was too long and too disorganized but I am not sure about 
many things, sorry for the mess.

Is there a development roadmap somewhere?

Any comments?-Patrick