What scripting language should I use

[Kirk McDonald]

Bill Baxter wrote:
> Kirk McDonald wrote:
>> Jari-Matti Mäkelä wrote:
>>> I've decided to create my next big game in D. It will be a rpg using D
>>> in the lower level stuff and an integrated scripting language for the
>>> game logic. Now, the only thing I'm not sure about is the scripting
>>> language. It needs to be object oriented / functional and somewhat
>>> portable (linux & windows).
>>>
>>> I've searched the dsource site. There is already more or less complete
>>> support for
>>>  - python (pyd)
>>>  - ecmascript (dmdscript, walnut)
>>>  - minid
>>>  - lua (bindings lualib, dlua)
>>>  - squirrel (bindings)
>>>  - euphoria (freudo)
>>>  - lisp (dlisp)
>>>
>>> Maybe there are other production ready implementations not listed here?
>>>
>>> It seems the pyd, minid and dmdscript projects are well maintained.
>>>
>>> The best option would be to fully integrate the scripting engine to my
>>> game. Using it via the C ABI should be ok, but requires a bit extra 
>>> work.
>>>
>>> Which one should I take. I don't want to end up using vaporware. The
>>> miniD projects looks interesting. I know dmdscript works, but I think
>>> those other languages might be better suited for my game.
>>
>> There are perhaps three things to be aware of if you're considering 
>> using Pyd:
>>
>> 1) Linux support is still missing. I get the impression a new GDC 
>> release is close, and it is my hope that this will change at that 
>> time. It's worth pointing out that CeleriD (Pyd's build system) 
>> already works in Linux for building extensions written to the raw 
>> Python/C API.
>>
>> 2) At the moment, Pyd is written from the standpoint of writing 
>> extensions to Python in D, rather than embedding Python in D. This is 
>> not to say Pyd wouldn't be helpful if you wanted to embed Python in 
>> your D code (at the very least, Pyd has the most up-to-date bindings 
>> for the Python/C API), but your code will essentially just be using 
>> the raw C API for many things.
>>
>> 3) I'm still cramming features into Pyd at a decent clip. I don't 
>> expect the existing API to change much, but be aware that new features 
>> are being added about as fast as I can think of and implement them.
>>
> 
> Yes after enthusiastically recommending Python, I should add the 
> disclaimer that I've never used PyD.  ;-) Nor was I aware of points 1 & 
> 2 above.
> 
> Kirk -- I would definitely encourage you to think about how to make Pyd 
> more useful for embedding as well.  I think that's one place where 
> Python advocates tend to be unrealistic.  Sometimes embedding is just a 
> better fit, like when you want to add a bit of external scripting 
> capability to an app.  Probably one of the best known examples of Python 
> use is in Blender, which embeds.
> 
> I wonder what's missing in Pyd?  Pyd must have a way to let you call a 
> Python function from D, otherwise your D extension module's ability to 
> interact with python is quite limited (no callbacks to Python for 
> instance).  Is it just the python startup code?
> 
> --bb (who was hoping to use Pyd for embedding python at some point)

Embedding is of great interest to me. It's on the short list of things I 
want to do. (Also on that list: Improve the way CeleriD handles object 
files; and a custom type conversion registry.)

Callbacks are easy: delegates are a convertible type. This means that 
Pyd can convert any callable Python object into a delegate, and any 
delegate into a callable Python object.

Supporting embedding requires two things:

First is wrapping the pertinent sections of the Python/C API. The 
PydObject class (which was actually the first thing I wrote in Pyd) is 
the first swipe at this. It wraps any PyObject*, and overloads a whole 
bunch of operators, so that using a PyObject in D acts as much like 
using it in Python as possible.

PydObject is only the first step; there are a number of helper functions 
needed to really make it useful. (The 'py' template function is the most 
important: it accepts any arbitrary D item and returns a PydObject.)

Another important class (which I have started writing, but which is not 
in SVN yet) is one that wraps the Python interpreter itself. This class 
would have methods like 'Import' (for importing Python modules) and 
'Run' (for running strings with Python code in them, as in 
PyRun_SimpleString), and would control initialization and finalization 
of the interpreter.

Yet another thing to support is extending the embedded interpreter. That 
is, exposing your D functions and classes to the Python code being run 
in your embedded interpreter. I have already added some support in this 
vein, though I haven't documented or tested it, yet. For the most part, 
this is just like writing a regular extension.

The second thing required in order to support embedding is working out 
the build method. This is probably easier than the first thing. When 
used in this way, Pyd becomes just another library to link against and 
directory to put on the library search path. (In fact, you'd have to 
link against the Pyd library -- which doesn't exist, yet -- and the 
Python DLL.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org