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