When will the typePtr of a Tcl_Obj be set correctely?

From: Martin Lemburg EDS PLM solutions (martin.lemburg_at_eds.com)
Date: 10/31/03 

Date: 31 Oct 2003 11:33:15 -0800

Hello,

I work in a C(++)-API with tcl objects, the tcl obj command gives me.

Following examples make me ask "why this?":

  % proc a {a} {dummyCmd $a;}
  % a [expr {3.0}]

-> the expression result is a double inside dummyCmd

  % proc a {a} {dummyCmd $a;}
  % eval a [expr {3.0}]

-> the expression result is reduced to have no type inside dummyCmd
(typePtr == NULL)

  % proc a {a} {eval dummyCmd $a;}
  % a [expr {3.0}]

-> the expression result is reduced to have no type inside dummyCmd
(typePtr == NULL)

  % proc a {a} {dummyCmd $a;}
  % eval [list a [expr {3.0}]]

-> the expression result is a double inside dummyCmd

  % proc a {a} {eval [list dummyCmd $a];}
  % a [expr {3.0}]

-> the expression result is a double inside dummyCmd

  % proc a {a} {dummyCmd $a;}
  % uplevel 0 [list a [expr {3.0}]]

-> the expression result is double inside dummyCmd

  % proc a {a} {dummyCmd $a;}
  % uplevel 0 a [expr {3.0}]

-> the expression result is reduced to have no type inside dummyCmd

  % proc a {a} {uplevel 0 [list dummyCmd $a];}
  % a [expr {3.0}]

-> the expression result is double inside dummyCmd

  % proc a {a} {uplevel 0 dummyCmd $a;}
  % a [expr {3.0}]

-> the expression result is reduced to have no type inside dummyCmd

Why reduces the tcl command eval the types to "no-type"?
Why does uplevel the same? Ok, ok - it relies on the same mechanisms.

If I have to expand a list with "eval" to use it with a command, than
all argument object types will be lost?

That would not be good, because sometimes it seemed good to my to rely
on the objects type to care differently for objects, depending on the
object type.

Another thing is about the type of an object, that looks like an
integer, a double or a boolean, and it has or has not a type in my
C-written command:

  % proc a {a} {dummyCmd $a;}
  % a 1

-> is the "1" a string and an integer and has the integer type inside
dummyCmd

  % proc a {a} {eval dummyCmd $a;}
  % a 1

-> is the "1" a string and an integer and has after the usage of eval
no type inside dummyCmd
(typePtr == NULL)

  % proc a {a} {dummyCmd $a;}
  % a 3.0

-> is the "3.0" a string and a double, than why 3.0 has no double type
inside dummyCmd
(typePtr == NULL)

  % proc a {a} {dummyCmd $a;}
  % a [expr {1 == 1}]

-> shouldn't the result of the boolean expression be a boolean, it is
an integer inside dummyCmd

  % proc a {a} {dummyCmd $a;}
  % a [expr {1 == 1 ? "true" : "false"}] # working with tcl v8.3.5

-> why is the result of the expression now a boolean inside dummyCmd,
when strings are returned by expr

  % proc a {a} {dummyCmd $a;}
  % a true # working with tcl v8.3.5

-> "true" is a boolean inside dummyCmd

So ... does the interpreter or the bytecompiler care for strings
looking like a special object type or not?

Using the string "true" or "false", the object in C is automatically a
boolean.
Using the string "1.0", the object in C is only a string, not a
double.
Using the string "1", the object in C is automatically an integer - if
no eval/uplevel is used.

Can somebody enlight me to answer all the "why"s?

Thanks!

Martin Lemburg

Relevant Pages