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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk