Re: [boost] Boost::Tcl

From: Maciej Sobczak (prog_at_[hidden])
Date: 2005-10-03 02:27:24

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/