Language Design – weak types and easy marshalling

Weak/Dynamic typing

One of the things I really like about Tcl is how very, very dynamic it is. It’s possible to replace just about everything ‘on the fly’, including control commands like if and while (in Tcl, they’re just commands, not special syntax).

Like Lisp, Tcl gets a lot of its flexibility from its simplicity, and one of the ways that things are kept simple is via the concept of “Everything Is a String”. Some people erroneously recall the early days of Tcl and take this to mean that Tcl represents everything as a string internally, making it very slow for numerical operations. That hasn’t been true for something like 8 years – Tcl values are translated into a more appropriate internal representation ‘on demand’. However, the concept still gives you lots of flexibility:

set a b

You don’t have to quote things – they default to strings – the variable ‘a’ now contains the value ‘b’.

set lst {a b c d e}

No fiddling around with lots of syntax – the above is defined as a string (we could have used “” to group the words), but it gets turned into a list

llength $lst
5

Things are automatically converted into the type you want to work with. Of course, this also makes it really easy to work with code as strings and vice versa:

proc until {cond code} {
    while {1} {
        uplevel $code
        if { [uplevel [list expr $cond]] } { return }
    }
}

set i 0

until {$i == 10} {
    puts "i is $i"
    incr i
}

and so on and so forth.

Ruby (and Python) handles things a bit differently than Tcl does. Even though it’s still very dynamic, it is more strongly typed:

"5" + 5 # error

Whereas the same code runs just fine in Tcl – “5” is transformed into a number, because if the programmer is trying to add to it, they must want it to be a number. On the other hand, strong typing can help catch errors, may help make things clearer, and in corner cases, probably helps catch nasty surprises.

One of the things that Tcl’s system facilitates, at least with simple types (lists, strings, numbers, dicts) is ‘marshalling’ or ‘serializing’. Want to send a hash table down a socket?

 puts $sk $mydict

 # And on the other side:
 gets $localsk mydict
 dict get $mydict key

When you start treating it as a dictionary, it “just turns into one” – or throws an error. Good programmers will check for errors, but that goes for whatever language you use. This often comes in handy for code-creation, as well – it’s very easy to build up a string programmatically and then evaluate it, much as you might do with a list in Lisp.

It also makes coding short scripts… well, shorter, because you don’t have to fiddle around telling the language what you mean, in most cases. Treat it like how you want to use it, and it will work out what you want to do.

Hecl

Hecl comes into the picture, because I’ve borrowed a lot of design ideas from Tcl, but the language is still used by only a few people, so we’re free to hack on it and change things that we don’t like about Tcl. Lately, we’ve been having an interesting debate on the merits of Tcl style weak typing, vs stronger Ruby-style typing, as well as the string representation you get when you attempt to print a type:

http://sourceforge.net/mailarchive/message.php?msg_id=15254941

http://sourceforge.net/mailarchive/message.php?msg_id=15254942

There are certainly some things that could be improved in Tcl’s way of dealing with things – one area where it doesn’t do so well is in dealing with NULL values – you can’t really deal with that in a string, because a blank string is different from no value at all.

Wolfgang would like to go towards more Ruby-style values. I’m willing to consider most anything at this stage, because it’s interesting, and I like going over the possibilities, in order to make Hecl as useful as possible. “Everything is a string” has its limits in Tcl, in any case, because what ends up happening is that ‘complex’ types (files, say), are tied, via a hash table, to the C struct that actually implements them, meaning that the string representation is really only a pointer to something else, and isn’t “meaningful”, as it is with lists or dicts.

I think, though, that in this case I’ll mostly want to keep types weak/dynamic, as Hecl aims to be a complement, not a replacement for Java, so in many cases, I’d rather see it make nearly the opposite design decision, where it’s reasonable.

We’ll see, though, who knows what ‘type’ of interesting compromise we might end up with. Of course, I’m always happy to see new people join the discussion.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s