|
From: | Brian Tiffin |
Subject: | Re: [open-cobol-list] Bindings via perform statement? |
Date: | Mon, 15 Apr 2013 14:06:48 -0400 |
User-agent: | Opera Mail/12.14 (Linux) |
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 advancedanalytics on semi-structured data. The platform includes APIs for buildingapps 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
[Prev in Thread] | Current Thread | [Next in Thread] |