D as an extension language

[Bill Baxter]

Kirk McDonald wrote:
> For what it's worth, I think that D and Python go together quite nicely. 
> This is the whole point of Pyd, which hopes to do for D what 
> Boost.Python does for C++. (http://pyd.dsource.org) The concept of 
> prototyping with Python and dropping into D when speed is needed is a 
> sort of end-goal of Pyd's.

Yeh, that does sound like a very nice concept.  Except I seem to be the 
only one who's not so wild about Boost.Python.  Heavy dependencies, not 
so scalable to big projects from what I understand, and kind of odd 
syntax.  Browsing through the docs, PyD does look somehow a little more 
appealing though.  Maybe the lack of mystery macros like 
BOOST_PYTHON_MODULE, lack of ugly c++ member-pointer syntax 
(&Class::method), and using a more normal D style in your examples 
rather than trying to pretend you're writing a class declaration by 
naming the wrapper generator class "class_" and chaining .def's one 
after the other.  Also the second page of Boost.Python's tutorial being 
"let's learn how to use bjam so we can compile Hello World!" is kind of 
a turn off.  Celerid looks like a much nicer way to handle building 
simple extension modules.

> As for calling D code from C++, you should be able to call any D 
> functions that are declared extern(C). Analogous to calling C code from 
> D, you'll have to provide a header for C++ to #include, then just link 
> as needed. The two languages can't talk to each other directly, of 
> course, so you always have to go through this C layer.
> 
> There do exist tools to streamline this process to an extent, I believe, 
> but I can't say as I'm familiar with them. Sorry.

Would some sort of D-API for C be useful there?  For instance Python has 
its C-API from which you can create and manipulate basic python 
datatypes, muck with reference counts, etc.  How do you manipulate a D 
string from C, for example?

--bb