Updated 2018-07-02 08:06:52 by pooryorick

MJ 2016-08-18: 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:

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? edit

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.

See Also  edit

Every Word is a Constructor
More discussion of the same topic.