Re: [glob2-devel] Embedded scripting language (again)

[Martin Voelkle]

> I know this has been discussed before, again and again, but I think
> its about time we start taking it serioussly: I would like to begin
> work on embedding a scripting language in the 1.1 branch. So, lets
> stop the theorieticall stuff, most scripting languages, such as
> python, are going to be more portable than c++, and are very unlikely
> to cause determinism issues. And, if the language in question does
> cause a determinism issue, i can pick it up and change it early.
>
> I suggest we start looking at this from a dependancy standpoint. I
> would like to see python in the system, because of Boost.Python, it
> would be very easy to embedd, and the power, ease of use and
> portability of python makes it an ideal candidate. On the downside,
> python is a very large dependancy.
>
> There are certainly other languages, however. Lua is much more
> compact, but I'm much less familiar with lua. Its interface isn't bad,
> and things such as lua++ and luapp will make it easy to embedd, not as
> easy as python.
>
> I've heard you ask about the language Squirrel. I've looked into it,
> and it seems like a very nice, compact language, quite elegant by my
> standards, especially for a C-derived syntax. Then there is scheme.
> Scheme is very compact, like lua, infact its possible to import the
> entire language into our project as a single file, although we would
> be unlikely to do so. The language does have a lisp syntax, making it
> somewhat different than what we are used to.
>
> What should we pick? Don't think of it as a determistic or statespace
> problem, all the languages i've looked into can provide us with the
> assurrances we need. Think of it as a dependancy and usability review.
> We should decide now, and I can begin work soon.

I'd be very interested if you could provide references that confirm
that these runtimes do povide us with the assurances we need.
If you embed an existing runtime, you must also be careful about
security: we don't want maps to access files or open sockets by
themselves.

I think you are overlooking the problem. Retrofitting checkpointing
and determinism in an existing runtime is irrealistic for the python
runtime.

Talking about languages, I think python is a bit unintuitive for map
designers without a programming background. If you want a widely-used
and simple language, ruby fits better IMHO. JavaScript could also be
nice.

NCT: on thread per unit will probably never be possible for performance reasons.

Martin