Re: [boost] Boost::Tcl

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-01 19:42:50

Maciej Sobczak <prog_at_[hidden]> writes:

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

That makes no significant difference AFAICT.  Jam is similar in its
lack of types, and I'm sure a suitable back-end could be created for
Jam.  

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

That's very similar to often-used capabilities of Lua and capabilities
that Python has, but are less-used.  And it has little bearing on the
applicability of the universal front-end.

> 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. In addition, it is possible to alias commands from one such
> interpreter to another, which makes it even more interesting.

That sounds interesting, but it doesn't have any bearing on the
applicability of a universal binding mechanism AFAICT.

> In other words, a "universal" binding would need to be full of 
> fundamental compromises.

I don't buy it.  

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

There's a *huge* amount of overlap in the things that Boost.Python and
Luabind do, and want to do, which is why the authors started this
project.  I believe if you were looking harder for overlap with your
Tcl library you'd find it.

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