Re: [boost] Boost::Tcl

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-01 12:43:33

Maciej Sobczak wrote:
> Pavel Vozenilek wrote:
> 
>>You may perhaps take some inspiration in these Boost-like language bindings 
>>I know about:
>>
>>- http://cpptcl.sourceforge.net/ C++ interface for TCL
> 
>>These would likely deserve place in Boost but AFAIK they weren't suggested 
>>for review yet.
> 
> Which is inaccurate.
> 
> C++/Tcl was announced at Boost almost one year ago. After that I was 
> suggested to bring it to langbinding, which is an effort to provide a 
> universal back end to any language. At that time, the following two 
> things were (and still are) clear to me:

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.

> In fact, I don't believe that any such 
> universal base will be ever created, if not by finding a common 
> denominator which unfortunately might not be satisfying to anybody.

I don't think we ever had the delusion that there would be a universal 
anything, other than a universal C++ reflection utilities. Yes it was a 
dream but we know that each language will require context dependent 
treatment.

> Example 1: Tcl has a type "system" that is fundamentally different from 
> that of Python. In particular, in Tcl the type of a variable does not 
> depend on how the variable is set, but rather on how it is queried. For 
> example, the value "Boost" can be seen as a 5-char string, but "0" can 
> be used as *every* type in Tcl, be it bool, integer, string or even list 
> (whose only element can be again treated as any type, depending on how 
> we want to look at it) - this is very different from how the types are 
> treated in Python and largely influences what can be done on the binding 
> level. On the other hand, Tcl has no built-in (ie. on the interpreter 
> level) support for classes and inheritance, whereas Python has it.

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. For multi type languages, like Lua and 
Python, it would be M to N. The M to N is a superset of the 1 to N, so 
it can obviously be implemented with the same utilities.

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.

> Example 2: Tcl has an object-based approach to interpreters and there 
> can be *many* of them, even completely independent (this includes the 
> possibility to run them in separate threads). Any given interpreter can 
> be made "safe" by disabling certain commands, so that it is very easy to 
> create "jails" or "sandboxes" - very useful for applications that need 
> to execute untrusted scripts.

Same with Lua (and hence LuaBind), and almost the same with Python.

> In addition, it is possible to alias 
> commands from one such interpreter to another, which makes it even more 
> interesting.

Ooh, fun :-) I can't imagine testing such things would be easy.

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

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

> These two were the reasons for C++/Tcl to go ahead alone. In retrospect, 
> I think it was a good decision, especially if we take into account that 
> C++/Tcl is now a mature project with growing and interesting user base 
> and that at the same time langbinding did not do any progress.

I can understand why you chose to go ahead, and I agree that it was a 
good choice and I would have made the same choice in your shoes even 
knowing some of the insides of langbinding. But that is not an argument 
against the langbinding work, progress only happens if people put effort 
into something. If someone had put effort into langbinding over the same 
period of time it likely would have progress enough for it to be used 
not only in your work, but of others who face the similar script 
language binding task.

> Having said that, I take the opportunity to remind C++/Tcl here (well, 
> *you* did it first :) ). It was inspired by Boost, uses Boost and has 
> the old Boost licensing scheme. If during the last year the objectives 
> of Boost wrt scripting languages changed from what it was a year ago, 
> then I will be pleased to see it considered as a candidate for Boost.

The objectives of Dave, Daniel, nor I with regards to langbinding have 
anything to do with whether C++/Tcl can be part of Boost. That's up to 
_you_ and the Boost community at large within the framework of the 
submission process. If you want to see your library in Boost, you or 
someone sufficiently motivated needs to submit it.

And for practical matters, having something other than Boost.Python 
accepted with similar goals is likely to advance the langbinding effort 
for the simple aspect of it being a concrete domain data point to 
consider in the design of langbinding.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - Grafik/jabber.org