call by ? and mental models

We've stopped to take a look at how Hecl handles procedures and their arguments. Since Hecl is a command-based language that takes a lot from Tcl, one obvious thing to borrow would call-by-name:

set i 10
incr i
puts "i is now $i (11)"

Currently, though, it does call-by-reference for destructive commands like 'incr':

set i 10
incr $i
puts "i is now $i (11)"

Part of the thought behind this choice is that I want a consistent mental model for users, who I do not anticipate being programming language wonks, but rather those who would like to utilize Hecl to script applications for their cell phones, perhaps on a level on par with your average PHP user. In a language like PHP, variables always have a $ attached to them, which makes it easy for users to recognize that "that's a variable". I have a suspicion that Tcl's strategy of using foo here and $foo there may be confusing to new users, who must recall which one to use in which place.

Furthermore, I am curious what references or lack thereof do to people's conceptual models of a language - having two variables point at the same thing. For instance PHP gives you the & operator to create a reference, C gives you pointers, Ruby and Python let you assign one thing to another and, in some cases, modify the thing pointed at by both variables. This also has me wondering what Scheme/Python/Ruby style pass by value with some kinds of values being modifiable is like for newer users... whether that makes sense or is confusing to have some kinds of things that can be changed, and others that can't.

I'm currently searching for research and information on the topic, but in the meanwhile, what do you think?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

"funny character in front of a variable name"

The perl folks gave $ the name of a Sigil. Not sure if that terminology has caught on in other languages.

For all it's many faults,

For all it's many faults, Tcl's variables are pretty easy to understand: it has a clear distinction between the name of/reference to a variable and the value stored in that variable. E.g. 'var' is the name, '$var' is the value in referred to by 'var'. So 'incr i' clearly passes a reference to a variable and does something destructive to that variable. 'puts $i' passes the value in i to puts and does not do anything to the variable i.

Easy for you and I

But what I'm curious about is Joe PHP and the like. Will he be able to remember which is which in a group like this?

lappend foo 1 ; lrange $foo 0 1 ; lset foo 0 1 ; lindex $foo 0

I suppose you could say it's just a bad API design, perhaps borrowing from scheme and adding ! to the destructive ones might make it all clearer... still though, I think that not having that symbol (sigil, or whatever we want to call it) makes it just a tad harder to parse, mentally. But it's just a hunch, I don't have the means to back it up.

clarity -> verbosity?

Presumably it could be made more clear by not using sigil shorthand? $foo could become value_inside(foo) or something 'natural languagy' like that, but then the code might be horrible to many folks' eyes.

Actually, I really like the verbosity of AsmL when reading it side-by-side with equivalent C#. It might be neat to invoke the Deus Ex Machina of IDEs and say that the code could be written and read in either a compact or more verbose form, affording a wider range of people's mental preferences.


The problem is, I don't think even that much verbosity will help a newbie if he doesn't already know what it does. What would a new programmer think when he sees two identical lines of code, with one using 'value_inside(foo)' and the other just using 'foo'? "Isn't foo the value? Why do I need to access its value 'inside' in this case and not the other?" I think the best way to handle it is to assume that the person understands the concept already, since it's hopelessly impossible to try and explain it with only a couple words.


Right, that's sort of what I'm getting at. There may be, to someone not familiar with the language, something of an inconsistency, compared to, say, PHP or Perl where there's always a 'sigil' of some kind, with PHP being more consistent than Perl, which identifies different 'types' with different symbols.

There are worse things out there, but it is something that I've always wondered about Tcl and its relationship with new users.