A few months ago, I wrote in this space some speculation under the question, "What is a Variable?" [Hill] and would now like to explore that question a bit further. The Dictionary of Computer Science [DictCS] says that a variable is:
For someone who appreciates a pesky problem, this is great stuff. Alternative 3 passes the buck, alternative 4 doesn't get us very far, and alternatives 1 and 2 are the two of the views we are trying to pin down and reconcile. (The reader should not infer condemnation of this definition or promise of a better one.)
That piece on variables in January garnered some comments. Vincent Di Carlo mentioned the work of Simon Funk, with references, who observes and illustrates some of the difficulties connected to regarding a variable as a container, and the use of predication to alleviate that difficulty [Funk].
Peter O'Hearn mentioned Christopher Strachey, for which I commended and thanked him. But on reflection—that wasn't enough. Strachey's remarks on this subject deserve more attention [Strachey]. He brings up the complexity of the L-value (the address, or location; the variable identifier, in other words, on the left side of an assignment). He shows expressions in that place, and explicitly allows functions. We are completely used to the left-hand side of an assignment statement sporting an expression like A[i], an array name with an index to a particular element. This, of course, requires evaluation; in fact, this L-value is a function. Examples of L-values such as A[i+1] make that even more cogent. The variable itself varies, in other words, an affordance that has been played down in our more mechanical and precise development of programming languages.
This might suggest something about the informal view I attempt to exhibit. Here is a lightly-fictionalized story of variables from my small town, where everybody knows the local businesspeople.
I said to a friend, "I made a mistake-- The sewing machine repairman's name is not Victor, but I can't remember what it is." She said (now read carefully), "No, it's not not Victor. It's actually not Mercer." Right, of course... Victor was the repairman for vacuum cleaners, in the same shop, before then. But Mercer was the proprietor of the sewing shop, not the repairman. And she knew I was thinking of Mercer. As for the actual sewing machine repairman who was working for Mercer—let's call him X—he plays no part, and I have no clue as to his real name, except that it was neither Victor nor Mercer.
A gross translation of the pertinent sentences looks like this:
Not(X) = Victor We're calling this false!
Not(X) = Mercer We're calling this true!
I refrain from expressing those in any notation approaching symboic logic for fear of inducing some sort of modeling monstrosity. What is the variable at play here? It's X only in the sense that it's not. X is the foil. If X were the principal, we could reason this way:
X != Victor
X != Mercer
Both are true, so that the imposition of standard semantics is not particularly revealing, and does not explain in what sense my friend was right. That's not what I was saying in the story; rather, I was shamelessly assigning to the L-value Not(X). As I recall, I had grasped the presence of negation when I entered the shop, once or twice, and called the repairman "Mr. Mercer," to which he finally replied, "I'm not Mercer. He owns this place." I had forgotten the details, but recalled the negation, and misdirected it. Does recalling it mean that the negation itself is the value of some variable, or is the negation a variable with a name as its value?
I offer no answer to that. It would be interesting as an exercise in formal representation under the laws of some system, perhaps generating a shadow referent for the placeholder that eventually resolves correctly into Mercer on its way to expressing a lack of identifier for X. The predications discussed by Funk might show the way. Yet the remarkable thing is that we tolerate, communicate, exchange, and exploit all those vagaries. We deal with them with no apparent discomfort, but rather recognition of the quirkiness with a laugh. William Kent makes the point that, even though we can't draw a principled distinction between the attribute and the relationship, the terms are still useful, which might be the most intriguing result of all [Kent].
So when our students ask what is a variable, we could state one of the variants given by the Dictionary of Computer Science, or something simple like "an expression for a memory location." They hardly ever ask. They learn it by exposure and experience, like we did.
Let's leave the last word to Strachey, in support of the motto he suggests:
If we attempt to formalise our ideas before we have really sorted out the important concepts the result, though possibly rigorous, is of very little value—indeed it may well do more harm than good by making it harder to discover the really important concepts. Our motto should be ‘No axiomatisation without insight’.
[DictCS] Andrew Butterfield and Gerard Ekembe Ngondi, editors. 2016. A Dictionary of Computer Science. Oxford University Press, 7th edition.
[Funk] Simon Funk. 2013. On Knowledge Representation.
[Kent] Kent, William. 1978. Data and Reality. North-Holland Publishing Company. Chapter 5.0. Attributes.
[Strachey] Christopher Strachey. 1967. Fundamental concepts in programming languages. These lecture notes for the International Summer School in Computer Programming are published in Higher-Order and Symbolic Computation, 13, 11–49, 2000, Kluwer Academic Publishers.
Robin K. Hill is a lecturer in the Department of Computer Science and an affiliate of both the Department of Philosophy and Religious Studies and the Wyoming Institute for Humanities Research at the University of Wyoming. She has been a member of ACM since 1978.
No entries found