gnucobol-users
[Top][All Lists]
Advanced

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

Re: [open-cobol-list] I want to create community code, not another islan


From: Brian Tiffin
Subject: Re: [open-cobol-list] I want to create community code, not another island
Date: Wed, 4 Sep 2013 01:41:22 -0400

Patrick;  If you do pursue such, I'd suggest looking to SWIG and we
can add COBOL to the mix of already interconnected languages.
http://www.swig.org/  We'd all get a lot of bang for that buck.  I'd
definitely help with that, as it's kinda on the mythical someday list
already.

Or, Vala and look to GLib introspection ala vapigen.  A bit more
limited than SWIG perhaps, but the GLib and GTK ecosystems are pretty
vast and pretty cool.

On 2.0, it brings OpenCOBOL closer to 20xx Draft and adds some
obsolete features in, ala ALTER.  Code base is still pretty much
intact, but extended, the main change being parser.y with a much
cleaner abstract tree and the preprocessor with full on directive
support.  It also brings a bunch of bugs we are going to have to fix.
Especially with the extended CALL support and (on the topic of your
post) the many datatypes that need to be supported in a BY VALUE state
and not just BY REFERENCE.

If we go GNU (and I still have all the paperwork to do), then part of
the proposal will be --with-guile scripting support.  Guile is a
little, umm, codey, but its the choice of GNU, so we'll buy in for the
pound if we buy in for the penny.  With the new EXEC engines popping
up, this opens a LOT of doors for making OpenCOBOL into a bit of a
powerhouse system.  User scripting 'for free' in applications and
developer scripting of the compiler would make for a pretty cool
thing.  (I can see Guile leveraged to tweak .conf settings 'in source'
along with source control over compile options, etc).  All optional of
course, as it'd be outside Standard.

<jokey mode, with some seriousness>
Oooh, I just looked a little closer.  SWIG supports R and Octave.
COBOL fiscals and R for the stats and Octave for converting page break
reporting into Ring Torus plots or even cooler as hyperbolic
paraboloids.  Mmmm, COBOL flavoured Pringles    :-)

Cheers,
Brian

On 9/3/13, Patrick <address@hidden> wrote:
> Hi Brian
>
> Thanks again for all your help !
>
> Do you think that the upcoming 2.0 release will change the existing
> codebase very much? Do you anticipate it being more additive then
> revolutionary?
>
> I finally figured out how to use ctags properly today and it is helping
> so very much. If I can get an hour to myself per day I bet I will
> understand the codebase in a few weeks or months.
>
> I did look at call.c and I am now looking at the cobc generated C to see
> how cobol is transformed into c.
>
> it might be neat to write libraries in hybrid c/cobol, C but using the
> open Cobol API. I could then make code that is callable from cobol, has
> cobol goodness baked in and is easy to mix with c/c++ libraries and
> c/c++ types(along with extern "c".
>
> Already the argument passing scheme in c is not what I thought it would
> be and it's got me thinking about ways to use it for easier c bindings.
> There is a call stack but there is also a module stack which has me
> thinking about how to merge the module stack with C++ methods for use
> with gui toolkits
>
> All the best-Patrick
>
>
>


reply via email to

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