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

[Martin Voelkle]

It's getting interesting...

> > > 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.
> The security thing is an issue in many embedded languages. You can
> generally solve it by providing a "limited enviroment", which means no
> importing io modules. or such things.

Is it possible to prevent the script from importing additional modules
and creating threads?

> > I think you are overlooking the problem. Retrofitting checkpointing
> > and determinism in an existing runtime is irrealistic for the python
> > runtime.
> Checkpointing in python is certainly do-able, infact i've done it
> before, very easily. A full vm dump is do-able within python itself,
> and of coarse also from pythons interface, just by looking into the
> "global dict", you can find everything you need to do a full vm
> marshal (marshaling) or serial (serialization). I have the python
> cookbook, and they demonstrate it fully.

Is the vm dump cross-platform?
Can you checkpoint the thread stacks too through the "global dict"?

> As for determinism, python is *more* deterministic than C++, having no
> such thing as "undefined behaviour" or "implementation defined", and
> doesn't cause problems like C/C++ does.

By determinism, I meant that the order of execution of coroutines has
to be deterministic.
I heard that python only supports system threads, but not coroutines,
which is the deterministic equivalent.

> >
> > 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.
> I think python is very intuitive. Its also got a very easy-to-learn
> syntax, just look at Scons for example, who also use python, and
> successfully teach people with no experience in python how to create
> scripts, and the advantage of being a full language shows when people
> get more experienced. And, last note, python is used more widely than
> ruby.

I still feel ruby is more newbie friendly. It's cleaner (no __init__
and self everywhere for example). In short, it seems more modern. Ruby
is used widely enough not to die soon.

This could be good news. If python meets all these needs, I'd say you
can start hacking with it (in a new branch please). But I prefer its
newer cousin ruby.

Martin