Opinions; Choice of scripting language

[btiffin]

Hello everyone,

I'd like your opinion on choice of embedded script interpreter for a compiled language. Just for arguments sake, let's say that language is COBOL.

So far I've got proof of concept layers for embedding;

• SpiderMonkey ECMA 262 (javascript)
  
• Tcl/Tk
  
• SQLite (not really Turing complete, but I'll list it anyway - the wrapper is a clone of the sqlite> prompt)
  
• externals - REBOL, bash, what have you
  

Others are already hard at work adding pgSQL and a perl interface.

And I was wondering what would/could be an OpenCOBOL uptake attractor for respectable developers such as yourselves.

I've got some spare time to twiddle and I'm leaning toward offering another embedding choice to OC programmers.

LUA? Ficl? Falcon? To name a few ... I'd prefer to hear your take on it. Python? BOO?

As an FYI, the SpiderMonkey engine and Tcl/Tk are both being given a nice professional polish, so they will be (optionally) provided along with OpenCOBOL at some point. SQLite is already more than usable, but data scripting and open scripting are two different animals.

I'd love to go embedded Ch, but it's commercial.

LUA?

Cheers and thanks in advance if you take the time to opine
Edit; typos (always with the typos)

[Euphoracle]

Personally, I love Lua. I'm totally biased towards it because I've used it both other people's work and my own (in C# at least) and it's such a nice language to work with both in the actual "code" and in the scripting code. It's elegant and human. Overall, I think of it as the ideal scripting language for me. It makes extending an application a breeze when implemented correctly* and has a very pretty and usable scripting syntax that's easy to follow. The mixmatching of types can sometimes produce cases where you have to doublecheck what's coming in from the scripting end, but other than that, it's just such a delight to use. It can be used to produce complex scripts (Tables are made of pure, liquid-cooled awesome) or simple, linear scripts.

Hurray Lua

[wtd]

Ruby, Io?

[Zeroth]

Lua. It has simply the smallest engine of all scripting languages. It has a nice, recognizable syntax, and it features coroutines.

[btiffin]

Ok, Lua is the next on the plate for a proof of concept pass.

And reading the About page, I've been misspelling it as an acronym. Smackdown! My apologies to the Pontifical Catholic University of Rio de Janeiro. Won't happen again.

And please don't take this post as a sign that I don't want more opinions. Gee, I might even listen to wtd and look into Io. Ruby? rebols dislike Ruby. Why? Jealous.

Thanks gentlemen,
Cheers

[Zeroth]

And after Lua, get Python. After Python, make a .net version of OpenCOBOL.

EDIT: To be more specific: Python is considered the industry's glue language. Having bindings will make OpenCOBOL marginally more attractive. And the same goes for a .net version of OpenCobol. .net is the up and coming contender for universal VM(the previous holder is Java).

[btiffin]

Lua ... nice ... a little bi-polar it seems; the changes between 5.0 and 5.1 being non-trivial when mixing and matching docs to code.

lua_dofile versus luaL_dofile ... oh well, can't hold back progress.

5.4 will have to wait till a few test heads are set up.

Lua:

-- Start -- Script - oclua.lua print("Lua prints hello") hello = "Hello OpenCOBOL from Lua" return math.pi, hello -- End

gives this output with a quick test wrapper - a c function as object file and COBOL caller with a pic x(32) result field pulling top of Lua stack

code:

C prints starting... Lua prints hello in C, tostring index 2: Hello OpenCOBOL from Lua in C, tostring index 1: 3.1415926535898 OpenCOBOL displays: |Hello OpenCOBOL from Lua        |

Thanks for the comments ... and please feel free to continue with opinions
Cheers

P.S. Zeroth; I'll disagree a little with the industry on considering Python the "glue". C is the glue. Python enables higher level abstractions and tool access sure ... but you can't (easily) write a mixed-language wrapper in Python (well, not that I've seen ... if it supports ELF, I take that statement back). Then again, I disagree with the industry at least twice a day; while waking up and while falling asleep.

Having said that, next time I'm twiddling, Python may get a wrap. I'm a fan of Guido's work.

[Zeroth]

btiffin @ Mon Oct 27, 2008 10:40 pm wrote:

P.S. Zeroth; I'll disagree a little with the industry on considering Python the "glue". C is the glue. Python enables higher level abstractions and tool access sure ... but you can't (easily) write a mixed-language wrapper in Python (well, not that I've seen ... if it supports ELF, I take that statement back). Then again, I disagree with the industry at least twice a day; while waking up and while falling asleep.

Having said that, next time I'm twiddling, Python may get a wrap. I'm a fan of Guido's work.

Well, considering some very large and profitable companies use Python as their glue language I'd take that as a hint. Industrial Light and Magic, NASA, Civilization 4, Rackspace, though granted NASA's not profitable. Now while it is not extremely common, I've seen evidence that it is becoming more common. There are countless small companies that use Python for a wide variety of purposes that don't ever get talked about. Everything from generating dummy images/sounds to handling XML conversion, to writing Webspiders. And lets not forget Google!

[btiffin]

Sorry Zeroth; I guess I should have been more clear. Yes, I agree the industry believes Python is glue, I disagree with that belief. Just so you know, I would pay more heed to your opinion than the "industry". En masse, humans are idiots (/me included), but I've rarely met an individual that didn't have redeeming qualities worthy of respect and admiration. Case in point; 90%+ of people use Windows. I completely disagree with that state of affairs, but I still like the people that use PC's.

But now for something completely different; you may be able to help me out;

code:

/* OpenCOBOL Python interface */ /* tectonics: cobc -c -I/usr/include/python2.5/ ocpy.c */ #include <Python.h> int main(int argc, char *argv[]) {     PyObject *pymodule;     PyObject *pyglobals;     PyObject *pylocals;     PyObject *pyresult;     PyObject *pystring;     int start = Py_file_input;     char *result;     int len = 0;     int res = 0;     Py_Initialize();     pymodule = PyImport_AddModule("__main__");     pyglobals = PyModule_GetDict(pymodule);     /* pylocals = PyModule_GetDict(pymodule); */     printf("Running string\n");     pyresult = PyRun_String("from time import time, ctime\nctime(time())\n", start, pyglobals, pyglobals);     printf("%x\n", pyresult);     pystring = PyObject_Str(pyresult);     printf("%d\n", PyString_Check(pystring));     printf("parsing string\n");     printf("len: %d\n", PyString_Size(pystring));     res = PyString_AsStringAndSize(pystring, &result, &len);     /* PyArg_Parse(pyresult, "s#", &result, &len); */     /* printf("%s\n", PyString_AsString(pyresult)); */     printf("Python returned: %d: %d : %s\n", res, len, result);     Py_Finalize();     return 0; }

Please ignore all the cruft ... this is my learn by experiment file.

My goal is to allow Python scripts to be interpreted, then pass the data back to an OpenCOBOL alphanumeric field (think char array). And at the Very High Level of embedding.

So given that I want to be able to execute arbitrary Python code (not knowing the type of the result of the script) what should be in pystring in this case? I'd expect a formatted datetime string, but the actual result from PyRun_String is coming back as "None". So, what am I missing? Using

code:

return ctime(time())

as the last script line ends up returning <NULL>. I want the datetime string (or whatever value an arbitrary script may return) to come through as the result.

Do I need to access a special variable in the global dictionary?

And yes, I have more to learn ... this is experimental so no safety checks are in place yada yada.

Cheers

Edit;

Learning more. I think I'm starting to see the intent of the Python API ... so perhaps the High Level embedding isn't going to cut what I need. I'll either cheat and document the OpenCOBOL interface as requiring an opencobol = ... somewhere in the script and pull that value out of the dictionary, extend Python with a returntoOC() function or burden the OC developer with the deep interface and expect them to name the function they want evaluated and use the proper API calls to retrieve the results. I'm leaning toward the easy cheat of opencobol = ... for the proof of concept pass.

Thanks again and I'd still appreciate other points of view on what people here would appreciate having access to for scripting within a compiled environment.

[Zeroth]

Take a look at this short discussion. The most python embedding I've ever done was writing a C module for an app that already had python embedded in it. :/

http://mail.python.org/pipermail/python-list/1999-April/000154.html

[btiffin]

Thanks Zeroth; read that one. It was one of the clue threads that I was wrong thinkin' in my expectations.

Always with the ditto and the Zeroth

Cheers

Edit; Adding
Anyone that cares; OpenCOBOL Lua interface
Still undocumented, lacking a few safety measures in the code, at least one more pass before it gets bundled.

http://www.opencobol.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=395&forum=1