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

[Brian Tiffin]

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.

Patrick;

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

> > SOURCE FORMAT IS FIXED
with
> > SOURCE FORMAT IS FREE
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
> envisioning.

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.

Kinda.

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

Yep.

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

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

Cheers,
Brian

> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list