Re: [boost] Boost::Tcl

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-03 10:45:13

Maciej Sobczak <prog_at_[hidden]> writes:

> Tcl *does* support many types. The problem is that there is no way to 
> discover what is the "current" type of the variable at any given time, 
> because in Tcl a variable can be only converted to reqested type, which 
> can fail or succeed. As a result, I don't see how to implement for 
> example function overloading there. In Python (and in other languages, I 
> think) you can ask what is the type of the variable and get some enum or 
> other type descriptor. In Tcl you can only *try* to convert to any 
> target type. Having a list of types, you can try to convert a given 
> value to all of those types - some will succeed, some will fail...

Actually, that model is almost exactly what Boost.Python uses to do
its conversions at function call boundaries, and basically everywhere
else.  Knowing the source Python type can make the "try" to convert to
some type a bit faster, but that's really an implementation detail of
the converters.

>> RE, object vs. procedural: Just like the original C++ implementation 
>> mapped to the procedural C, one can perform an equivalent mapping in 
>> scripting languages. And you have done this in your TCL binding library 
>> so I don't see your issue with it.
>
> There is a lot of cheating there and I'm not comfortable with the idea 
> of inheritance and virtual functions, for example. The way you do this 
> in Python is a lot different from what you can or cannot do in Tcl.
>
>>>Example 2: Tcl has an object-based approach to interpreters and there 
>>>can be *many* of them
>> 
>> Same with Lua (and hence LuaBind), and almost the same with Python.
>
> Sorry, the last time I checked it was virtually impossible to have two 
> Python interpreters that would not share any state. This was needed and 
> I failed to see how to do this (even using the low-level Python API), 
> whereas it is straightforward in Tcl.

It doesn't matter, though.  Independent interpreters is easy (and
often used) in Lua, and that's not at all in conflict with the notion
of langbinding.

>>>2. I don't see any *benefit* from building such a "universal" thing. I 
>>>think that users of different scripting languages form rather disjoint 
>>>audiences and any overlap here is too small to justify the effort to 
>>>create a universal language binding.
>> 
>> I think many of the users of other universal binding platforms out there 
>> would disagree with you here, for example all the people who use CORBA.
>
> I don't think that the same people are interested in interfacing to 
> *different* languages - that was the point. 
> There are some who want to 
> interface with Python, some who want to interface with Tcl, etc., but 
> I'm not aware of anyone who would ask for more than one language 
> binding. 

C++ library authors, in particular, would like to produce bindings for
their libraries that work with multiple languages.

> Thus, the only purpose of building a "universal" binding would 
> be to have the potential of code reuse and would target not final users, 
> but designers and developers of new bindings - and this is something 
> which I don't believe in. The reasons are as described previously - 
> extreme amount of work, much higher than that needed to create separate 
> bindings, even if each one is implemented separately from scratch, just 
> as was the case with C++/Tcl.

The langbinding library itself is a bit of work to do, but there's
absolutely no reason that using it should impose more work than using
Boost.Python, Luabind, C++/Tcl, or any of the others.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com