[MJ] - After watching Christian Gollwitzer and [dkf]'s talks on EuroTcl I was contemplating an idea for [Tcl9]. A big reason of Tcl's flexibility is brought by [EIAS], however this is a double edged sword.

   * It's slow.
   * It makes intellisense like tools virtually impossible.

So how about a Typed Tcl where you can define and use Tcl_Objs with a specific internal representation and conversion functions to other intreps without passing to string.

You would need to declare the value as a typed value and as soon as you play the EIAS card, you will get an error unless you make the shimmer explicit.

This has a couple of benefits.

   * You wont break EIAS (it just needs to be explicit) so if you use a part of Tcl which is not type aware you need to pass `toString $var` instead of `$var`
   * You can go fast if you have a direct `intrep_type_a` to `intrep_type_b` function defined.

This approach is complementary to the approach of speeding up Tcl by code analysis. Sometimes I will just know when I don't need [EIAS] but I will just need speed instead.

[DKF]: The current diagram of what types we've found in the [tclquadcode] work is:
!!!!!!
[tcl-types.png%|% width=500]
!!!!!!
Yes, it's a bit complicated. No, not everything is a string, but most things are (the things which aren't don't appear as values you can manipulate and so can be ignored).

**How could it look?**
======
   settyped a list {a b c d}
   puts $a;                  # error, can't use a tped Tcl_Obj as a string
   puts [toString $a];       # ok $a is now untyped
   dict get $a c;            # error if there is no list->dict conversion
   dict get [toString $a c]; # ok, EIAS
======

On second thought, this will require a library user to cast every returned value to an untyped Tcl value to prevent errors, so this seems to be similar to Java land `Object`.

<<categories>> Enter categories here