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