Maciej Sobczak <prog@msobczak.com> 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