Re: [boost] Boost::Tcl

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-02 23:03:52

Maciej Sobczak wrote:
> 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.

Yes. And I think the only way to answer what the common ground is, is 
through examples. Boost.Python and Luabind share a large amount of 
common ground as they are closer, language wise, to C++ than TCL and others.

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

I think it's both :-)

> Tcl *does* support many types.

Is that support internal? Or is it lexical?

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

I must say that's a big annoyance. Only thing I can think of to do is 
that in the TCL binding case the call dispatch just has to try each, in 
some preferred order, until something, or nothing works.

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

Interestingly I'm one of those asking for more than one language :-) I 
write a tool that currently uses Luabind to provide Lua scripting in the 
tool. But the tool is designed so that other scripting languages can be 
used simultaneously.

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

Yes, at minimum, binding implementors would benefit from an existing 
code base. For example type manipulations, and obviously the front end 
DSEL binding syntax.

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

That might be true for TCL, but as Dave said it's not true for Python 
and Lua. And likely is not true for most object oriented languages.

Anyway, I'm not trying to convince you to change the implementation of 
your project FWIW :-) Just voicing opinions as an interested party.

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