Embedded scripting language advice sought

[Jerry McAllister]

On Sun, Jan 18, 2009 at 06:41:59PM -0500, Linda Messerschmidt wrote:

> For a project I'm working on, I need to find an scripting language, and I
> have a long wishlist:

Oh Oh, you're going to start a religious war now.  
Well, good luck and be ready to take everything you hear with a shovelful
of salt or preferrably maybe something either mindnumbing or psychodelic.

////jerry


> 
> 
> - able to be "easily" embedded in a C++ application
> 
> - "real" object-oriented with inheritance (preferably multiple inheritance)
> 
> - able to implement object methods in C++ where needed
> 
> - "sandbox" operation (e.g. ability to suppress any file I/O & system
> libraries, but keep math and string libraries)
> 
> - thread-safe, or, at least able to have multiple coexisting execution
> contexts in one running process
> 
> - relatively user-friendly syntax (i.e. (not (lisp (based))))
> 
> - has to build and embed on FreeBSD
> 
> 
> This is a mathematical model, and the goal is to write certain
> high-performance parts in C++, but to provide the user a command-line style
> interface where they can "explore" interactively, examine/tweak data values,
> etc, and then override certain behavior by subclassing from the C++ base
> classes using the scripting language to see how it affects the next model
> iteration.  One thread is handling the model calculations, and one handles
> the user's exploration, with appropriate synchronization when changes are
> made.  (We are doing this already, but since the code is C++, only the data
> can be edited while it's running and inspection is limited to our hacky
> pseudo-language.)
> 
> 
> The obvious choice for this was Lua; it hits a lot of the marks, but not all
> of them and not all well.  I got as far as creating a Lua "object" in C++
> that exposes some core functionality, which is great, but when it comes to
> inheritance, and especially multiple inheritance, Lua's object model wasn't
> thrilling me.  Also, it uses setjmp for error handling, which I'm worried
> will mess around with C++ exceptions; they are already fragile enough in
> threaded applications.
> 
> 
> I do like Lua, but I'd really rather find an embedded scripting language
> designed from the start to support OO, if one exists.  Are there other
> alternatives I should look at?   Lua is to C as ______ is to C++?
> 
> 
> I tried to give Guile a look but a quick poll of the users vetoed the
> syntax.  Lua is clearly ahead in the user-friendly department.
> 
> 
> I also wondered if Python would be a good choice, but I'm just not sure
> about how well it handles having new code generated more or less on the fly
> in the middle of a running application.  I somewhat suspect that if it were
> done in Python, it would end up being a Python app with C++ add-ins, rather
> than a C++ app with an embedded scripting language.  That isn't a
> deal-breaker, of course, as long as it works; results matter.  That's not
> exactly "lightweight" though, and I'm not sure if (or how) Python sandboxes.
> 
> 
> One last "wouldn't it be nice" wish...  If the user creates something they
> particularly like on the fly, compositing up an object a piece at a time on
> the command line, it would be just grand if the scripting language were able
> to reproduce a class definition for that arbitrary object that could be
> saved or tweaked for later reference and reuse.  If not, we'll just have to
> abstract the editing process enough to keep one ourselves, which would
> probably be a bit user-unfriendly but hardly the end of the world.
> 
> 
> But with a wishlist this long and exotic, I'm afraid the question here is
> not whether something can do it all, but how disappointed I'm going to be.
> :-(
> 
> 
> I'm grateful for any language suggestions or feedback.  Is Lua as close as
> we can get?  Python?  Other?!
> 
> 
> Thanks!
> 
> 
> -LM
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"