Transcript Names

Variables
reference, coding, visibility
Rules for making names






permitted character set
maximum length, significant length
case sensitivity
special words: keywords or reserved
predefined names
association with data and processes
What features influence
readability and writability?
Variables – data representation
 high level version of memory
reference
 more general and useful model of
memory
 six attributes: name and address,
type and value, scope and lifetime
What features influence
readability and writability?
Attributes of variables
name
address
type
value
lifetime
scope
Address - memory location
 Actual location of data, low level
 name-address relations may be
one to one
one to many: e.g., same name used for different
variables in different methods
many to one (alias): e.g.: formal parameter in
method call refers to same object as actual
parameter
D Goforth COSC 3127
5
Type: code and range
 Simple (primitive) types: bit code for
storage
 Composite types: subtypes and
organization
Type determines:
 range of possible values
 operations on values
D Goforth COSC 3127
6
Values
 Actual sequence of bits as interpreted
by codes and organization
 Abstract memory cell - memory space
for a value without considering inside
structure
e.g., double ‘cell’ is 8 bytes in java
e.g., object manipulation
D Goforth COSC 3127
7
Values
 Implementation - inside view
 Application - abstract view
some languages allow inside view of
simple data types
e.g.: C has bit level operations
D Goforth COSC 3127
8
Binding - setting attributes of
entities
 E.g. a variable (entity) has six
attributes that must be bound to it.
x = 6.0; // binds value to variable with name x
 All entities of a programming
language have attributes: data types,
operators, keywords, programs, etc.
D Goforth COSC 3127
9
Binding Time
 Time when binding of attributes
occurs is a major distinguishing
feature of languages
 Binding Time Line:
D Goforth COSC 3127
10
Binding to variables
 Static - before execution
 Dynamic - (before and) during execution
java e.g.:
int mVal = 0;
final double yearLength = 365.248;
mVal = 1000;
D Goforth COSC 3127
11
Binding type to a variable
how
Explicit Implicit
when
Static
Dynamic
X
D Goforth COSC 3127
12
User-defined types
Simple types
 enumerated
e.g. in pascal:
type suittype = (spade, heart, diamond, club);
var trump suittype;
trump := diamond;
 subrange
e.g. in Ada:
subtype DAY_OF_MONTH is INTEGER range 1..31;
START_DATE: DAY_OF_MONTH;
D Goforth COSC 3127
13
User-defined types
Compound types
 anonymous types
 named types
e.g. in Ada:
type YEAR_LIST is array (1..366) of INTEGER;
A, B: YEAR_LIST;
C: array (1..366) of INTEGER;
D: array (1..366) of INTEGER;
D Goforth COSC 3127
14
Dynamic typing
 variable gets type from value
assigned to it
 type can change during execution
 expensive in performance – tracking
type
 e.g. APL, LISP
Storage (address) binding
 static allocation: variable is
associated with one address for entire
program – efficient but inflexible
(e.g., no recursion, waste space)
 e.g., java class variables
 dynamic allocation: memory allocated
when declaration executed
Stack-dynamic memory
 allocations for a called
procedure are
‘stacked’ on
allocations for calling
procedure
 lifetime: proc
execution
procedure main
{ int x,y,z
a(x)
}
procedure a(int w)
{ int t,x
b(t)
allocation for b: w,e,d
allocation for a: w,t,x
allocation for main:x,y,z
}
procedure b(int d)
{ int e,x
}
Heap-dynamic storage
 explicit: heap of memory is allocated
on specific request: pointers (c) and
references (java)
lifetime: till deallocation(c) or gc(java)
 implicit: with dynamic typing
lifetime: till variable retyped
Type checking-compatibility of
types in an operation
e.g.: assignment, expressions,
procedure calls:
Type error: expected type and actual
type don’t match
Coercion: legitimate change of actual
variable to expected type
e.g.: 4 * 5.6
double y = 100;
String s = “max: “+ y;
Strong typing
 all type errors are detected reliability
Question: java is strongly typed: can
type checking be done at compile
time??
Strong typing
Question: java is strongly typed: can
type checking be done at compile
time??
NO: some variables can contain
different types – must check at run
time
e.g. Object obj; // can reference object
from any class
Type compatibility
For user defined simple types:
type date = 1..31;
var
birthday: date;
count: integer;
...
count := birthday;
Pascal: type error
name type compatibility
(OK with structure type compatibility)
Scope
 Range of accessibility of variable
 scope in object-oriented languages is
distinct and sometimes tricky
(chapter 12)
 scope in imperative (procedural)
languages depends mostly on
procedures
Scope in imperative languages
 Static scoping - visibility depends on
structure of source code file
determined at compile time
 Dynamic scoping - visibility depends
on procedure calls
determined at execution time
Scope definitions – imperative
languages
 block – bounded part of a program –
e.g., procedure
 scope – range of visibility of an
identifier, e.g., variable name
 local scope – block where identifier is
delcared
 non-local scope – other blocks where
identifer is visible
Typical imperative program
A
program A
B
C
type f,g,h
var x,y,z
procedure B
var v,x
begin
...
end
begin
...
end
D
E
F
Static Scoping
 scopes nested according to file
structure – determined at compile
 what identifiers are visible from a
scope?
 which variable for multiply-defined
identifier is visible?
Static example: pascal
 sample of code
 visible variables
at each block
 visible procedures
at each block
 partial scope and
forward reference
Static scope impedes information
hiding
 unintended access to variables and
procedures is hard to prevent –
nesting scopes
partial solution: flat procedure hierarchy
(c)
Dynamic scope – stack dynamic
variables
 Non-local scopes based on procedure
calls
 procedure may have different scopes
each time it is executed
Dynamic example: “pseudopascal”
 sample of code
 visible variables
at each block
 visible procedures
at each block
 partial scope and
forward reference
Dynamic scope
 all local variables visible during
execution
 difficult to read programs – must
know calling order
partial solution: use static scoping and
get ‘dynamic’ power by parameter
passing