Re: [open-cobol-list] Bindings via perform statement?

[Brian Tiffin]

On Mon, 15 Apr 2013 13:15:41 -0400, Patrick  
<address@hidden> wrote:

> Hi Everyone
>
> Just a nutty idea on my lunch break....
>
> Via the call statement we can call programs in other languages. If those
> other programs are compiled right in with the cobol executable then they
> can potentially maintain state as global variables and static variables
> within functions.
>
> With the C program Foo we can call the function Foo-You but the call
> syntax could get a bit tiresome with many arguments and many of the
> arguments may even be the same each time. For instance with the Lua
> language API the first argument to each function is usually a pointer to
> the Lua state struct, normally called L.
>
> I actual don't want to use Lua right now but there are all sorts of
> libraries I do.
>
> If each call statement was wrapped in a perform statement, could we
> don't potentially reduce the typing and make a Cobol-Way binding to a
> given library?
>
> If this was logical, I wondering if I could even write a binding
> generator, that would automatically wrap each function.
>
> -Patrick

Nice, not nutty.

I've been on the quest to find useful linkable libraries since I first  
bumped into OpenCOBOL.  They are everywhere, and way fun. :-)

SWIG might help with hints, but, FUNCTION-ID support is where all the real  
ease of use will begin.

I'm still not ready (willing?) to pick the fight that may well be  
inevitable to get the 2.0 source tree out into the wild, but it's been far  
too long now and getting kinda ridiculous.

On a different note, I've been pondering what might be possible from a  
Single Character Read Interpret Programming Tool (ala cbrain), but with an  
eye toward usefulness and not just esoterica.

cbrain, for instance, allows quoted strings in the source tape, and those  
strings are looked up as dynamic shared objects and called.  Sadly the  
stack frames are assumed as single int in, single int out.  Describing  
simple stack frames shouldn't be overly complicated.  (This would really  
be nothing but a sidetrip though, while we figure out how to get User  
Defined Function support into everyone's hands).

Another angle to ponder is EXEC support.  There are forces at play that  
lead to including Guile as a supported extension engine with the compiler  
proper.  That support can be manual, or precompiler pass, or (the way I'd  
like to see it) EXEC directly supported as part of OpenCOBOL, probably  
built into the preprocessor along with its COPY/REPLACE features.

Patrick; this is an area that holds my interest, and "things" will  
happen.  Not sure what things, but things.

Cheers,
Brian

> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for  
> building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> open-cobol-list mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/open-cobol-list