Computer Programming Languages -- Variables

By Herbert J. Bernstein

In mathematics variables are the quantities which can assume more than one value, as opposed to constants which have a fixed value. Variables are often used as parameters which determine the results obtained from functions. In working with computers, the term variable has been adopted as the asbtraction for a portion of memory within which different values may be stored at different times during the execution of a program.

• Names
• A name is a symbolic string by which we refer to an abstract or concrete entity
• The same name may be used to refer to multiple entities (e.g. overloaded operators)
• A given entity may have multiple names (e.g. octal, decimal and hexadecimal representations of the same number)
• The most useful names are mnemonic; they remind us of the entity referred to.
• Constants referred to by strings of digits of the appropriate value
• Some languages allow constants to be named
• Functions referred to by names such as "cos", "pow"
• Languages restrict permitted names
• To avoid confusion among entities (e.g. variables vs. constants)
• To avoid conflict with language constructs (e.g. "for")
• To conserve resources (e.g. limiting lengths of names to conserve symbol table size)
• Historical reasons (e.g. upper case only)
• Issues
• What set of characters to allow (alphanumeric, specials, all)
• What limits to set on meaningful name length (1, 6, 7, 32, unlimited)
• Treat upper and lower case as distinct
• What words to disallow (reserve)
• Variables
• Many properties: name(s), storage mapping(s), contents, type(s), associated methods, ...
• Multiple names for the same variable
• Multiple names for the same storage mapping (aliases)
• Storage mapping addresses called l-values
• Contents called r-values
• Methods have always been associated with types, emphasized with objects
• Binding
• Associating properties with names
• Static (compile time) binding -- saves time during execution
• Dynamic (run time) binding -- simplifies programming
• Different properties may be bound (and unbound) at different times
• Lazy evaluation -- postpone binding of values as long as possible
• Dynamic typing -- flexible but cannot check types at compile time
• Dynamic storage allocation
• Raises the issue of lifetime
• Raises the issue of dynamic binding
• Raises the issue of dynamic type checking
• Stacks, heaps, interaction with pure and impure code
• Explicit and implicit storage allocation, garbage collection
• Scope
• Portions of code within which a given instance of a variable is known
• e.g. formal function parameters known only within a function definition
• Scope may be static or dynamic
• Static scope determined by the relationships of declarations at compile time
• Dynamic scope determined by the relationships of declarations at run time
• Binding a properties to a name at run time in an outer level of procedure declaration, effective for procedures call deeper within the thread of execution
• Blocks with local declarations
• Allow for limited scope (and perhaps lifetime) without having to declare a new procedure
• Nesting allows variable declarations to be brought near their use
• Types
• Simple types have implicit methods
• Complex types may lack associated methods
• Complex types may be homgeneous (arrays) or heterogeneous (structs, unions)
• Objects allow methods for complex types
• Overloading allows aliasing of methods (multiple meanings for the same method)
• Initialization
• Static -- like an assignment statement, but at compile time
• Dynamic -- implicit assignment statement at start of lifetime

Last Updated on 2 March 2000
By Herbert J. Bernstein
Email: yaya@bernstein-plus-sons.com