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.