Re: [boost] Boost::Tcl

From: Maciej Sobczak (prog_at_[hidden])
Date: 2005-10-02 16:55:48

Rene Rivera wrote:

> I'm going to disagree with your clarity :-)
> 
>>1. Different scripting languages and the abilities of their interpreters 
>>can be sooo different that finding a universal ground for all of them 
>>would take years of design only.
> 
> Perhaps. But at some level all scripting languages end up implemented, 
> or interfaced, with C. This, and other language design aspects, 
> increases the likelihood that they share some basic structure which can 
> be exploited in the binding case.

Which is true. The question remains what is the common ground.

> RE, universal type vs. multiple types: Regardless of how many built in 
> types there are in the script language the bindings have to handle type 
> translations. In the case of single type languages, like TCL and *Rexx, 
> that translation will 1 to N.

I don't really get it (or you didn't get what I wrote).
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...

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

>>In other words, a "universal" binding would need to be full of 
>>fundamental compromises.
> 
> And that's where I disagree. And at some level I would think you don't 
> believe that or you would not have modeled CPPTCL on Boost.Python.

The only thing that is "modeled" is a syntax used for binding:

i.def("foo", &bar);

and the similarities end just after this point.
There was *inspiration* but no "modeling".

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

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/