Is there any interest? -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Yes! On Fri, 30 Sep 2005 21:17:43 -0400, Alan Gutierrez <alan-boost@engrm.com> wrote:
Is there any interest?
-- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
"Alan Gutierrez" wrote:
Is there any interest?
Of course. Is there anything to take look at?
One might look at http://excruby.sourceforge.net. It is modeled on Boost.Python, though is not as complete. We have, however, been using it in production code for a few years now, so it is "complete enough". We're wrapping some of TAO and ACE with it and use ruby to make CORBA calls into our C++ programs. -- Chris
You may perhaps take some inspiration in these Boost-like language bindings I know about: - http://cpptcl.sourceforge.net/ C++ interface for TCL - http://clipp.sourceforge.net/ C++ interface for Javascript - http://luabind.sourceforge.net/ C++ interface for Lua (not very active now) - http://sourceforge.net/mailarchive/forum.php?forum=boost-langbinding Attempt to create universal back end usable for interfacing to any labguage (project currently sleeping) These would likely deserve place in Boost but AFAIK they weren't suggested for review yet. If able I would be happy to help with interface to Ruby. /Pavel
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: 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. 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. In addition, it is possible to alias commands from one such interpreter to another, which makes it even more interesting. In other words, a "universal" binding would need to be full of fundamental compromises. 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. 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. 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. Here's the link again: http://cpptcl.sourceforge.net/ -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
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
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.
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). Tcl *does* support many types. 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...
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.
There is a lot of cheating there and I'm not comfortable with the idea of inheritance and virtual functions, for example. The way you do this in Python is a lot different from what you can or cannot do in Tcl.
Example 2: Tcl has an object-based approach to interpreters and there can be *many* of them
Same with Lua (and hence LuaBind), and almost the same with Python.
Sorry, the last time I checked it was virtually impossible to have two Python interpreters that would not share any state. This was needed and I failed to see how to do this (even using the low-level Python API), whereas it is straightforward in Tcl.
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.
The only thing that is "modeled" is a syntax used for binding: i.def("foo", &bar); and the similarities end just after this point. There was *inspiration* but no "modeling".
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. 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 - 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. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
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
Rene Rivera wrote:
Tcl *does* support many types.
Is that support internal? Or is it lexical?
It's internal. In fact, the internal representation of type is something kind of union that keeps and caches "the last used representation". It was different in early versions of Tcl where everything was string, but for some time the internal representation is typed for obvious performance reasons. For example: set i 7 incr i After this, 'i' is a variable that holds value 8, which internal representation is integer, since this is how it was used the last time. If you want to again use 'i' as a number, no conversion is needed and the operations will be performed directly on the integer representation. However, if you do this: set j [string length $i] then 'j' will be set to... 1 (a number), because that's the string-wise length of 'i' and because the last used representation of 'i' is now string ("8"), it will be stored as a string from now on. Until, of course, you will try to use it as something else, when it can again change its internal representation.
I must say that's a big annoyance.
Depends on what you want to do. It is just the way it was done and from the Tcl point of view there is nothing bad with it. Moreover, there is still nothing bad if you interface with C. The problem begins only when you try to do something "modern" in C++ binding and totally breaks with function overloading, for example.
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.
In what purpose? I don't try each, I just don't overload commands. The command name unambiguosly leads me to the list of expected types (one for each parameter position) and I *know* the target type, so no need to "try" until found. If the conversion fails, then the parameters are just wrong. This greatly simplifies the library and, what's most important, is not surprising to Tcl programmers. It may be seen as limitations from the C++ side ("I cannot export my funky set of overloaded functions!"), but I don't see it being a problem in so-called "practice", at least in the domain where I use it.
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 :-)
Cool! Are you using more than one scripting language? Then, use for example Boost.Python to export to Python and C++/Tcl to export to Tcl. I think you can even squeeze the definition blocks in the same .cpp file, or even help yourself with some preprocessor stuff to reduce code repetition. The fact that these two do not share any logic internally does not change the way you can use it.
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.
And I don't question it. I'm just convinced that for any framework there exist a language that does not fit. Knowing Tcl a little bit I'm convinced that it will not fit into langbinding, whatever it ends up to be. Having said that, there are three things that will never fly at Boost: - universal language binding - universal database access lib - universal GUI framework The whys of it are not only technical. I think that Boost is old enough (and has deep enough mail archives ;) ) to back this claim. This is my very *humble* opinion of course, and I wish Boost that I'm mistaken.
Just voicing opinions as an interested party.
-- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/
On 10/3/05, Maciej Sobczak <prog@msobczak.com> wrote:
It's internal. In fact, the internal representation of type is something kind of union that keeps and caches "the last used representation". It was different in early versions of Tcl where everything was string, but for some time the internal representation is typed for obvious performance reasons. For example:
Isnt this the same way PHP is? It seems that the TCL bind could have some overlap with a PHP bind(when one is created). regards, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Maciej Sobczak wrote:
Rene Rivera wrote:
Interestingly I'm one of those asking for more than one language :-)
Cool! Are you using more than one scripting language?
I haven't gotten to the point of having anything other than the Lua bindings. But the plan is to have more. And Python would be the next easiest to do.
Then, use for example Boost.Python to export to Python and C++/Tcl to export to Tcl. I think you can even squeeze the definition blocks in the same .cpp file, or even help yourself with some preprocessor stuff to reduce code repetition. The fact that these two do not share any logic internally does not change the way you can use it.
Well yes obviously. By the way I use my own CPP IDL language to generate the Lua bindings, and many other things automatically. But it would be an easier, faster job, if all the bindings where the same because writing and testing all the macro expansions is a slow painful process.
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.
And I don't question it. I'm just convinced that for any framework there exist a language that does not fit. Knowing Tcl a little bit I'm convinced that it will not fit into langbinding, whatever it ends up to be.
Having said that, there are three things that will never fly at Boost: - universal language binding - universal database access lib - universal GUI framework
Perhaps, I can't tell the future, but at minimum various utilities that come from those will definitely make it into Boost. -- -- 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
"Maciej Sobczak" <prog@msobczak.com> wrote
Having said that, there are three things that will never fly at Boost:
- universal language binding - universal database access lib - universal GUI framework
I assume you mean by "universal", libraries as part of the C++ standard? I am most interested in the particular reasons that a universal GUI framework will never fly. Could you provide some more of your analysis? regards Andy Little
Maciej Sobczak <prog@msobczak.com> writes:
And I don't question it. I'm just convinced that for any framework there exist a language that does not fit. Knowing Tcl a little bit I'm convinced that it will not fit into langbinding, whatever it ends up to be.
To really know whether it could fit, you need to understand not only Tcl but the langbinding design. So far your remarks have shown little understanding of what we are doing. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Sorry for delay, I started on Tuesday but I have time to finish it only now. Maciej Sobczak wrote:
Cool! Are you using more than one scripting language?
I'm sure many users would be happy if firefox supported their favorite scripting language like elinks browser does ( http://elinks.or.cz/ ).
And I don't question it. I'm just convinced that for any framework there exist a language that does not fit. Knowing Tcl a little bit I'm convinced that it will not fit into langbinding, whatever it ends up to be.
I believe that many scripting languages will fit into langbinding model. Some time ago I scanned quickly Ruby, Python, Lua, COBRAScript, Java and C# to see they type system. No wonder there are many differences between them but in spite of this they share common properties as well. First, we should analyze as many languages as we can and to classify them. Then, language model for langbinding should be introduced. It would help users to get the whole picture rather quickly and figure out how to develop C++ classes in langbinding neutral manner. It would help backend writers to fit they language into the model and they would need to document only language-specific features. -- Alexander Nasonov
Maciej Sobczak <prog@msobczak.com> writes:
Tcl *does* support many types. 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...
Actually, that model is almost exactly what Boost.Python uses to do its conversions at function call boundaries, and basically everywhere else. Knowing the source Python type can make the "try" to convert to some type a bit faster, but that's really an implementation detail of the converters.
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.
There is a lot of cheating there and I'm not comfortable with the idea of inheritance and virtual functions, for example. The way you do this in Python is a lot different from what you can or cannot do in Tcl.
Example 2: Tcl has an object-based approach to interpreters and there can be *many* of them
Same with Lua (and hence LuaBind), and almost the same with Python.
Sorry, the last time I checked it was virtually impossible to have two Python interpreters that would not share any state. This was needed and I failed to see how to do this (even using the low-level Python API), whereas it is straightforward in Tcl.
It doesn't matter, though. Independent interpreters is easy (and often used) in Lua, and that's not at all in conflict with the notion of langbinding.
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.
C++ library authors, in particular, would like to produce bindings for their libraries that work with multiple languages.
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 - 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.
The langbinding library itself is a bit of work to do, but there's absolutely no reason that using it should impose more work than using Boost.Python, Luabind, C++/Tcl, or any of the others. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Maciej Sobczak" wrote:
- http://cpptcl.sourceforge.net/ C++ interface for TCL [...]
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:
[ snip details ]
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.
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.
Well, obviously last year's "objectives of Boost" didn't survive too long. Matured project with user base looks like good qualification for review. /Pavel
Maciej Sobczak wrote:
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.
For something to be "considered as a candidate for Boost", you just need to submit a formal review request.
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
* Pavel Vozenilek <pavel_vozenilek@hotmail.com> [2005-10-01 09:30]:
You may perhaps take some inspiration in these Boost-like language bindings I know about:
- http://cpptcl.sourceforge.net/ C++ interface for TCL - http://clipp.sourceforge.net/ C++ interface for Javascript - http://luabind.sourceforge.net/ C++ interface for Lua (not very active now) - http://sourceforge.net/mailarchive/forum.php?forum=boost-langbinding Attempt to create universal back end usable for interfacing to any labguage (project currently sleeping)
These would likely deserve place in Boost but AFAIK they weren't suggested for review yet.
If able I would be happy to help with interface to Ruby.
Pavel Sorry for responding twice, but my response to this message was not copied to the list. I thought I'd respond again, since all these reesources are a going place to start discussion. Thanks for all the references. If luabind and clipp contributors don't chime in here, I'll send them a message. It appears that all the above code is M.I.T. or similiar, and they all claim to be influenced by Boost::Python, so it seems like the interface for Ruby is going to be pretty well defined. I'd like to get something going that I can work with, first, if that's okay, and then worry about genralizing for for NetRexx later. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Alan Gutierrez <alan-boost@engrm.com> writes:
Is there any interest?
Daniel Wallin and I have a project -- called langbinding -- to produce a unified binding engine that works for any number of interpreted languages. If you are thinking about doing something similar to Boost.Python, please consider working with the code we've already written and following through on our intent there. -- Dave Abrahams Boost Consulting www.boost-consulting.com
* David Abrahams <dave@boost-consulting.com> [2005-10-01 18:26]:
Alan Gutierrez <alan-boost@engrm.com> writes:
Is there any interest?
Daniel Wallin and I have a project -- called langbinding -- to produce a unified binding engine that works for any number of interpreted languages. If you are thinking about doing something similar to Boost.Python, please consider working with the code we've already written and following through on our intent there.
David Of course. Where can I get the source? http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/langbinding/ The files are empty there. It may sound naive, since this is what CORBA was all about, but I'd like to be able to provide an interface that allows C++ to call scripted objects in a C++ way (what ever that is). I'm imagining that there would have to be an interface to setup a context, retrieve a context, provide callbacks or observers, how would you call into a functional programming language, etc. I'm not leafing through the July CUJ and there's: http://www.noodleglue.org/noodleglue/noodleglue.html - Java And EPerl but the link is jumping out at me. Which is why I thought that a language specific binding was the way to go. I only want Ruby today. Since I feel you need to know something about a scripted language to make the most of it. Maybe that's not necessary, or desireable. Most langauges do useful things form the constrained interface of the command line. Actually, ignore all that, I'm getting ahead of myself. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Alan Gutierrez wrote:
Where can I get the source?
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/langbinding/
The files are empty there.
There in the "langbinding" branch. If you get it from a cvs client you can specify the branch. For viewcvs you can see the files if you go into the "Attic" directory, select the "langbinding" as they get added as deleted files for branches, the go back to the parent. Which gives you this URI: http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/langbinding/?only_wi... Now you can go into the subdirs to look at the files :-) -- -- 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
* Rene Rivera <grafik.list@redshift-software.com> [2005-10-02 14:18]:
Alan Gutierrez wrote:
Where can I get the source?
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/langbinding/
The files are empty there.
There in the "langbinding" branch. If you get it from a cvs client you can specify the branch. For viewcvs you can see the files if you go into the "Attic" directory, select the "langbinding" as they get added as deleted files for branches, the go back to the parent. Which gives you this URI:
http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/langbinding/?only_wi...
Now you can go into the subdirs to look at the files :-)
I've got them now. Thank you. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
* Alan Gutierrez <alan-boost@engrm.com> [2005-09-30 21:17]:
Is there any interest?
There is interest. Survey results... http://engrm.com/blogometer/2005/10/02/ruby-c-bindings-survey/ Including the actions that I'm going to take next. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
* David Gruener <gruenedd@idmt.fraunhofer.de> [2005-10-06 06:29]:
Alan Gutierrez wrote:
Is there any interest?
YES!
Cool. I'm going to start up by working with the langbinging code to get a couple "Hello, World!" calls between the two. How do people feel about langbinding? -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Gruener <gruenedd@idmt.fraunhofer.de> [2005-10-06 06:29]:
Alan Gutierrez wrote:
Is there any interest?
YES!
Cool.
I'm going to start up by working with the langbinging code to get a couple "Hello, World!" calls between the two.
I don't really have the time, but I'll try to help you if I can. -- Dave Abrahams Boost Consulting www.boost-consulting.com
* David Abrahams <dave@boost-consulting.com> [2005-10-07 16:12]:
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Gruener <gruenedd@idmt.fraunhofer.de> [2005-10-06 06:29]:
Alan Gutierrez wrote:
Is there any interest?
YES!
Cool.
I'm going to start up by working with the langbinging code to get a couple "Hello, World!" calls between the two.
I don't really have the time, but I'll try to help you if I can.
Everyone, FYI. Checked in the Langbinding source into my Subversion repository. There are no build files for Langbinding, so this is going to be a slow start. I've checkout code from all the other bindings mentioned in this thread, for study and reference. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Abrahams <dave@boost-consulting.com> [2005-10-07 16:12]:
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Gruener <gruenedd@idmt.fraunhofer.de> [2005-10-06 06:29]:
Alan Gutierrez wrote:
Is there any interest?
YES!
Cool.
I'm going to start up by working with the langbinging code to get a couple "Hello, World!" calls between the two.
I don't really have the time, but I'll try to help you if I can.
Everyone, FYI.
Checked in the Langbinding source into my Subversion repository.
Why is that a good idea?
There are no build files for Langbinding, so this is going to be a slow start.
Probably, sorry.
I've checkout code from all the other bindings mentioned in this thread, for study and reference.
Cool. Please keep Daniel Wallin in the loop on Langbinding-related issues. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Alan Gutierrez <alan-boost@engrm.com> writes:
There are no build files for Langbinding, so this is going to be a slow start.
Probably, sorry.
Hm, did you also check out the boost-root/libs/langbinding directory? There's a libs/langbinding/build/Jamfile present.
I've checkout code from all the other bindings mentioned in this thread, for study and reference.
Cool. Please keep Daniel Wallin in the loop on Langbinding-related issues.
Or even better keep us all informed by posting to the langbinding list :-) -- -- 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
* David Abrahams <dave@boost-consulting.com> [2005-10-12 10:51]:
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Abrahams <dave@boost-consulting.com> [2005-10-07 16:12]:
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Gruener <gruenedd@idmt.fraunhofer.de> [2005-10-06 06:29]:
Alan Gutierrez wrote:
I'm going to start up by working with the langbinging code to get a couple "Hello, World!" calls between the two.
I don't really have the time, but I'll try to help you if I can.
Everyone, FYI.
Checked in the Langbinding source into my Subversion repository.
Why is that a good idea?
If I'm going to change code I use revision control. What's the problem?
There are no build files for Langbinding, so this is going to be a slow start.
Probably, sorry.
Not compliaining, just noting that it needs to be done.
I've checkout code from all the other bindings mentioned in this thread, for study and reference.
Cool. Please keep Daniel Wallin in the loop on Langbinding-related issues.
I'm posting this to the boost mailling list, if you want me to Cc you Daniel, please let me know. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Abrahams <dave@boost-consulting.com> [2005-10-12 10:51]:
Alan Gutierrez <alan-boost@engrm.com> writes:
Checked in the Langbinding source into my Subversion repository.
Why is that a good idea?
If I'm going to change code I use revision control.
What's the problem?
It should probably be developed in the Boost CVS. Otherwise we'll have to somehow integrate your revision history. -- Dave Abrahams Boost Consulting www.boost-consulting.com
* David Abrahams <dave@boost-consulting.com> [2005-10-12 11:36]:
Alan Gutierrez <alan-boost@engrm.com> writes:
* David Abrahams <dave@boost-consulting.com> [2005-10-12 10:51]:
Alan Gutierrez <alan-boost@engrm.com> writes:
Checked in the Langbinding source into my Subversion repository.
Why is that a good idea?
If I'm going to change code I use revision control.
What's the problem?
It should probably be developed in the Boost CVS. Otherwise we'll have to somehow integrate your revision history.
I'm imagining that my first attempts at a Ruby implementation are going to be something less than historic. I was going to try to set up an XCode project, and trace through some code. Plus, I thought I might write some "Hello, World!" programs using other bindings to see how they work. It's just my sandbox, really. My message was to note that I'm setting myself up to doodle, that I haven't lost interest. -- Alan Gutierrez - alan@engrm.com - http://engrm.com/blogometer/
participants (14)
-
Alan Gutierrez -
Alexander Nasonov -
Andy Little -
Caleb Epstein -
Chris Uzdavinis -
David Abrahams -
David Gruener -
Deane Yang -
Felipe Magno de Almeida -
Johan Nilsson -
Maciej Sobczak -
Pavel Vozenilek -
Peter Dimov -
Rene Rivera