[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Patrick
Subject: [open-cobol-list] future Developments, Brain Storming
Date: Wed, 13 Mar 2013 17:40:05 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20121215 Icedove/3.0.11

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]