Words matter


Yesterday, during a very nice presentation by Ohad Kammar at Carnegie Mellon, the discussion got derailed, in part, because of a standard, and completely needless, terminological confusion involving the word “variable”.  I’m foolish enough to try to correct it.

The problem is that we’ve all been taught to confuse variables with variables—that is, program variables with mathematical variables.  The distinction is basic.  Since time immemorial (well, at least since al Khwarizmi) we have had the notion of a variable, properly so-called, which is given meaning by substitution.  A variable is an unknown, or indeterminate, quantity that can be replaced by any value of its type (a type being, at least since Russell, the range of significance of a variable).  Frege gave the first systematic study of the quantifiers, and Church exploited the crucial concept of a variable to give the most sharply original and broadly applicable model of computation, the \lambda-calculus.

Since the dawn of Fortran something that is not a variable has come to be called a variable.  A program variable, in the sense of Fortran and every imperative language since, is not given meaning by substitution.  Rather, it is given meaning by (at least) two operations associated with it, one to get its contents and one to put new contents into it.  (And, maybe, an operation to form a reference to it, as in C or even Algol.)  Now as many of you know, I think that the concept of a program variable in this sense is by and large a bad idea, or at any rate not nearly as important as it has been made out to be in conventional (including object-oriented) languages, but that’s an argument for another occasion.

Instead, I’m making a plea.  Let’s continue to call variables variables.  It’s a perfectly good name, and refers to what is perhaps one of the greatest achievements of the human mind, the fundamental concept of algebra, the variable.  But let’s stop calling those other things variables!  In my Practical Foundations for Programming Languages I coined (as far as I know) a word that seems perfectly serviceable, namely an assignable.  The things called variables in imperative languages should, rather, be called assignables.  The word is only a tad longer than variable, and rolls off the tongue just as easily, and has the advantage of being an accurate description of what it really is.  What’s not to like?

Why bother?  For one thing, some languages have both concepts, a necessity if you want your language to be mathematically civilized (and you do).  For another, in the increasingly important world of program verification, the specification formalisms, being mathematical in nature, make use of variables, which most definitely are not assignables!  But the real reason to make the distinction is, after all, because words matter.  Two different things deserve to have two different names, and it only confuses matters to use the same word for both.  This week’s confusion was only one example of many that I have seen over the years.

So, my suggestion: let’s call variables variables, and let’s call those other things assignables.  In the fullnesss of time (i.e., once the scourge of imperative programming has been lifted) we may not need the distinction any longer.  But until then, why not draw the distinction properly?

Addendum: It seems worth mentioning that in PFPL I have a novel (afaik) treatment of the concept of a reference, which is clarified in a subsequent post.

About these ads

30 Responses to Words matter

  1. jamesiry says:

    I”ve had a related discussion many times, usually in response to a claim that “Haskell doesn’t have variables.” I’ve usually convinced the other party that they’re confused about what they mean by “variable” by pointing out that programmers frequently use terminology like “immutable variable” (or “final variable” or “const variable”) to talk about variables that are not or even cannot be mutated. So if “variable” means mutable then they’re talking about immutable mutables which clearly makes no sense. That whatever they mean by “variable” it does not necessarily mean “mutable.” From there I can start down the path of explaining what a variable really is and that mutation is a different thing.

  2. omerzach says:

    But if everyone called them assignables eventually some poor foreign programming language designer would come up with a great language whose only fault was syntax like “ass x := 7″.

  3. What’s with all the sour-puss reaction to this? We all call procedures “routines”, or functions “methods” sometimes. We have names like “protocol”, “interface” and “typeclass” that have overlapping meaning, depending on the context. How is it that “variable” is the only point of neurological stagnation for programmers?

    It’s a way better word!

  4. keithb says:

    There’s already a good term for this: “l-value”. L-values are values that can appear on the left hand side of an assignment.

    • I don’t agree with this. Assignables _are not values_, so calling them “l-values” is wrong or misleading.

    • mhelvens says:

      That doesn’t sound right for two reasons:

      * ‘l’ refers to ‘left’. So do we need a different name when a programming language uses a left-to-right assignment operator?

      * ‘value’ is also misleading, as Robert Harper notes.

      I think “l-value” is just what compilers call it.

  5. How about “stateables” instead since many “assignables” cannot be assigned to normally after creation but can still vary during the course of program execution?

  6. Point taken, but not for all languages.

    In Python, ‘variables’ should not be called ‘assignables’, because you can’t really assign to them. ‘a = 1′ does not assign ‘1’ to the box ‘a’. Rather, it *creates* a name ‘a’, in the current scope, for the object ‘1’. it sounds like a small distinction, but it’s actually almost the opposite, and makes a big difference to code like this:

    a = ['x']
    b = a
    a = a + ['y']
    print(b)

    Assigning assumes that ‘a’ has some kind of existence before the assignment, which isn’t true (at least for the first line above). If you think it terms of assigning values, you’ll get the wrong answer about what this code does (unless you also assume that assignment does copying of objects, which it doesn’t do).

    So in Python they should be called ‘names’.

    • It’s useful to distinguish the declaration of an assignable from an assignment to it.

    • Sridhar Ramesh says:

      You can totally (re-)assign to “variables” in Python. You’ve illustrated just that with your third line above.

      It just happens to be the case that Python picked this silly syntax which makes declarations and re-assignments look the same (and then some stupid voodoo rules for when to parse ‘=’ as making a declaration of a new variable and when to parse it as re-assigning to an existing variable…). But underneath the superficial syntax, Python is just the same as any other typical imperative language in this respective.

    • Sridhar Ramesh says:

      I suppose you might claim that the third line also creates a new variable named “a”. But that can easily be countered:

      a = ['x']
      if random.randint(0, 1) :
      a = ['y']
      else:
      a = ['z']
      print(a)

      If each = was creating a brand new variable, then the second and third a above would be completely different variables, and thus the a in the last line could not be referring to both of them; it would at most refer to one or the other. But, of course, it does refer to both of them, because they are the same variable (or rather, assignable), the same as in the first line.

      I suppose you could still cling to the claim “No, it’s still the case that there’s no re-assignment in Python. = creates new variables, always; it’s just that…” through some epicycles or another, but only through enough epicycles as to get this to behave exactly the same as if Python’s “variables” were assignables. Because they are.

    • gasche says:

      Luke, I think of the “=” operator as assignment, yet get the correct answer about this code: it is ‘+’, not ‘=’, that does the copying here.

      You should consider the following example:

      >>> a = ‘x’
      >>> b = lambda: a
      >>> a = ‘y’
      >>> b()
      ‘y’

  7. gasche says:

    I would rather describe assignables as variables whose values are (mutable) *locations*; you then need to explain that in most contexts, those locations are implicitly coerced to the value they themselves point to — when they are defined.

    This way, you have only one concept of variable/binding/substitution, and you compose it with this notion of mutable location to get “mutable variables”. The price to pay is the need to define when those coercions happen, but that will be simple for simple imperative languages and scale when you want more complex things.

    • In your terminology it’s the “location” that is the assignable.

    • gasche says:

      In that case, I’m not sure I understand what is the difference between this existing concept of locations and your idea of assignables. About locations, I like the fact that they are manipulated using the standard building construct. You can desugar what you write `decl a := e1 in e2` would be expressed by `let a = ref e1 in e2`. `a` changes status as it becomes a proper variable, and can be considered in the usual way — being understood that `ref 1` is an effectful expression and cannot be substituted before being reduced to a value.

      I realize that it is comfortable to consider assignable/locations as “related to variables” if you want to present first a stack allocation discipline for them, which mirrors lexical scope. But is this the reason for this choice?

      I would think that there is less reason for mistake if one describes location/assignable as values (whether or not you allow them to be written into locations or returned from functions; this can be controlled by typing), rather than as “not variables, but assignables”.

    • Assignables admit disequality, variables do not. That is, it makes no sense to ever depend on x and y being different variables, because this is not preserved under substitution, but it makes perfect sense to talk about a and b being different assignables, because they can never be identified with one another (no aliasing is possible). This is an important distinction that is the source of errors elsewhere in language design (notably, the treatment of communication in the \pi-calculus).

    • gasche says:

      > Assignables admit disequality, variables do not.

      Of course, but you could express this as well by using variables denoting locations, where locations are values that admit a disequality test. In the simple case where you only have locations to integers (or integer assignables), you would even define the equality test as a function of the language.

      Maybe my question wasn’t clear: what is the downside with the existing technique of adding a new class of values, “locations”, that admit assignation/dereference operations, and using the existing binding constructs of the language to denote such values? Why do you prefer to introduce this (related) concept of “assignable” that is not a value, but not a variable either, and is manipulated through a specific binding construction?

      I thought maybe that was favored by the choice of starting with stack-scoped assignables, that naturally follow a lexical binding discipline. Maybe you also find the binding construct (decl a := e in e) is more suggestive of the semantics of enlarging the store than a (ref e) primitive would be.

    • Well, the full answer is in my book, and is hard to summarize in a brief reply. What you’re calling “locations” is probably synonymous with my “assignables”; I admit that one could have chosen another word, but my main point is that it should not be “variable”. However, I would point out that the issue is NOT to do with scope or allocation extent. The concept of name binding, and the associated concept of reference, is used throughout the book in various ways. With respect to mutable storage cells, I model them as “(scope-)free assignables”, using scope extrusion to give them global scope.

  8. andrejbauer says:

    So how precisely did poor Ohad get ripped apart? Did anyone warn him about the audience at the PL seminar?

    • He didn’t, and we didn’t. There was confusion about an example that hinged on having in play at the same time: an assignable, a variable, and a substitution. The ensuing confusion prompted this post.

  9. mhelvens says:

    You’re right, of course. :-) In the beginning of my computer science studies I was sometimes confused about this distinction, and it would have helped if both concepts had proper names.

    That being said, no one will actually do anything about it, as I’m sure you realize. Even to me, ‘assignable’ doesn’t sound right, because the term ‘variable’ has already been burned into me.

    • It grows on you, trust me.

    • mhelvens says:

      I’m sure it would grow on me. But that’s not the point. Virtually every programmer in the world uses the term ‘variable’, and if I start using ‘assignable’, they may simply not understand me.

      On my free time, I’m working on a programming language. I’ve been considering calling your assignables something other than ‘variable’ (though I was leaning towards ‘mutable’). But I think it may just confuse potential users. I feel forced to bend to convention.

    • Sridhar Ramesh says:

      For what it’s worth, mhelvens, I too lean towards a name like “mutables” in my own head. “assignables” just doesn’t quite have the right connotations for me; after all, even traditional mathematical variables are assigned values (e.g., as in some sense happens to the parameters of a function when it is called on particular inputs).

      But even in breaking old convention, there is value in agreeing on a new convention, and as “assignable” has already been chosen and used in at least one significant text, it might as well serve as the new convention to rally round.

  10. Nick Barnes says:

    Yeah, but 60 years too late.

  11. Grauenwolf says:

    While you are at it…

    Stop calling things ‘objects’ in programming. If you can’t touch it, it isn’t really an object.

    And stop using the word “class” because it has nothing to do with learning.

    Of course “structure” is right out. Why I can’t even walk in it.

    An integer in FORTRAN isn’t a integer in mathematics, so we need a new word there too.

    Any talk of interfaces is just plain silly; everyone knows an interface is something to do with sewing.

    And finally, lets stop using the word variable in mathematics to mean an unknown constant. The very word means “apt or liable to vary or change” or as a noun, “something that may or does vary”.

Leave a Reply

Please log in using one of these methods to post your comment:

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

Follow

Get every new post delivered to your Inbox.

Join 1,294 other followers

%d bloggers like this: