[Top][All Lists]

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

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

From: Brian Tiffin
Subject: Re: [open-cobol-list] future Developments, Brain Storming
Date: Wed, 13 Mar 2013 19:54:25 -0400
User-agent: Opera Mail/12.14 (Linux)

On Wed, 13 Mar 2013 17:40:05 -0400, Patrick <address@hidden> wrote:

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.


OpenCOBOL reads code that compiled back in 1972 UCOB (OC probably compiles earlier sources, but 72 is as far back as I found a sample of). Let 1985, 2002, 20xx come through in my humble opinion. If someone wants old-school, let them code old-school. If they are a boss, they can enforce that on teams. If not, let progress, progress.

You'll never make everyone happy, but the way I see it; I've tried old school and new school source code with OpenCOBOL and both compile just fine. The best of both worlds. Heck, you can mix

every other line of code if you'd like.

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.

For my part, I put Report Writer on my plate and it will get in the compiler someday. Japan may do COMMUNICATION SECTION, but what I'd really like to see is someone attack the intrinsic function ALL keyword.

FUNCTION MAX(ALL table) etc.  That would be some nice backfill.

I'm looking forward to trying SPLIT keys as well. Joe seems to be coding some good code.

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.

Ahh, Peter Dashwood. I agree to disagree with Peter all the time. He's a fan of .NET and I see that ship sinking someday. I could be wrong, but I'm not a fan of proprietary tools. Applications sure, but tools? I like to have access to the sources, even if only to satisfy curiousity and to see if the tool may be "calling home" to track things I may not care to have tracked, like business related dealings and all the other paranoid privacy stuff. I prefer to give up my privacy knowingly.

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.

Yes. And if we can get 2.0 out the door. FUNCTION-ID support is going to be just grand for making toolkits.

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

Again with the 2.0; with -frelaxed-syntax identifiers can be 61 characters (deemed the hard limit), 31 normally.

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.

If we go to Object COBOL, first step is FUNCTION-ID then a look to generating C++ instead of C which will make Object COBOL a lot easier on the brain. (Or Vala style and leverage GObject, maybe?).

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

Wicked cool those.

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

I'd lean toward doing that after a move to C++ source intermediates, and FUNCTION-ID means being able to fling COBOL group structures around like candy.

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.

I'm with you.  Drop me a note to the From email address on this message.

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'd like to see GNAT and OC link up. I spent a few days with GPS as a potential IDE for OpenCOBOL development. I don't ever feel the need for an IDE, so I stopped, but I still see it as worthwhile.

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.

In this case, I'd lean to stealing code from Vala and using "vapigen" style headers. Name mangling can be a NP-Hard problem (I use the term loosely). Most decisions on naming lead to ambiguities or non human readable solutions.

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.

Umm, you can actually.  And this gets even better in later test cuts of OC.

I was new when I wrote the GTK sample and wouldn't do it that way a second time around. We can call libc functions directly by name. For 1.1CE you require wrappers only for VOID returns, some macros, extern "C" {} C++ calls and for rare wonky C call frames that just don't map to COBOL syntax. Roger did an excellent job on the CALL verb. We'll likely never get away from the problem of macros though, at least not without a preprocessor.

The sample Python bindings are in pure COBOL, except for callbacks, which require a thin one liner of C (well, 4 if you include proper defensive programming).

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.

I'm not going to, but yes people can (and maybe should). I'd prefer the conf file system as it is today. Perhaps with a little more strict wrist slapping for production shops. OC can be made to error out on some features, or just warn or ignore or compile. Leave the 85, 2002 decisions to the shop master and let the compiler be capable of all of it, in my humble opinion.

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

A team in Japan is about to unleash some code on the forge. They have some of the character set issues fixed with tweaks to PIC N national (well, and a default CURRENCY symbol of the yen mark and Simon is on the tag to correct that before we merge the changes into the CE branch.)

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

Not a mess.  A nice list.

Is there a development roadmap somewhere?

There used to be. The lead developer (Roger While) is not really leading anymore, and out of respect we have been holding off on some of the angles we could cover. I'll be pestering Keisuke Nishida and other players to see how we might get out of the current gridlock that is holding 2.0 hostage from public release. It's been 4 years now, time to pick a fight.

Any comments?-Patrick

No, not really.  ;-)


Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
open-cobol-list mailing list

reply via email to

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