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

[Bradley Arsenault]

On 2/20/06, Martin Voelkle <address@hidden> wrote:
> > 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.
>
> 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.

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

>
> NCT: on thread per unit will probably never be possible for performance 
> reasons.
>
> Martin
>
>
> _______________________________________________
> glob2-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/glob2-devel
>