chapter 7: DATA TYPES - IN PROGRAMMING LANGUAGES

Copyright © 2009 Elsevier
Chapter 7:: Data Types
Programming Language Pragmatics
Michael L. Scott

Data Types
• We all have developed an intuitive notion of what
types are, but what's behind the intuition?
– collection of values from a "domain" (the denotational
approach)
– internal structure of a bunch of data, described down to the
level of a small set of fundamental types (the structural
approach)
– equivalence class of objects (the implementor's approach)
– collection of well-defined operations that can be applied to
objects of that type (the abstraction approach)

Data Types
• Denotational are a more formal, mathematical view
of things.
• We generally combine a structural approach with the
abstraction approach in object oriented
programming: a set of data plus operations defined
on that data.

Data Types
• What are types good for?
– implicit context
– checking - make sure that certain meaningless
operations do not occur
• type checking cannot prevent all meaningless
operations
• but it catches enough of them to be useful
• Polymorphism results when the compiler
finds that it doesn't need to know certain
things

Data Types
• STRONG TYPING has become a popular
buzz-word
– like structured programming
– informally, it means that the language prevents
you from applying an operation to data on
which it is not appropriate
• STATIC TYPING means that the compiler
can do all the checking at compile time

Type Systems
• Examples
– Pascal is almost statically typed
– Java is strongly typed, with a non-trivial
mix of things that can be checked
statically and things that have to be
checked dynamically
– C is not strongly typed, but it is statically
typed
– Python is strongly typed, but is dynamic
and not static

Type Systems
• Common terms:
– discrete types – countable
• integer
• boolean
• char
• enumeration
• subrange
– Scalar types - one-dimensional
• discrete
• real

Type Systems
• Composite types:
– records (or structures)
– arrays
• strings are perhaps the most useful here
– sets
– pointers
– lists: defined recursively
– files

Type Systems
• ORTHOGONALITY is a useful goal in the
design of a language, particularly its type
system
– A collection of features is orthogonal if there
are no restrictions on the ways in which the
features can be combined (analogy
to vectors)

Type Systems
• For example
– Pascal is more orthogonal than Fortran,
(because it allows arrays of anything, for
instance), but it does not permit variant records
as arbitrary fields of other records (for
instance)
• Orthogonality is nice primarily because it
makes a language easy to understand, easy
to use, and easy to reason about

Type Checking
• A TYPE SYSTEM has rules for
– type equivalence (when are the types of two
values the same?)
– type compatibility (when can a value of type A
be used in a context that expects type B?)
– type inference (what is the type of an
expression, given the types of the operands?)

Type Checking
• Type compatibility / type equivalence
– Compatibility is the more useful concept,
because it tells you what you can DO
– The terms are often (incorrectly, but we do it
too) used interchangeably.

Type Checking
• Certainly format does not matter:
struct { int a, b; }
is the same as
struct {
int a, b;
}
We certainly want them to be the same as
struct {
int a;
int b;
}
Be

Structural Equivalence
• But should:
struct {
int a;
int b;
}
• Be the same as:
struct {
int b;
int a;
}
• Most languages say no, but some (like ML) say
yes.

Type Checking
• Two major approaches: structural
equivalence and name equivalence
– Name equivalence is based on declarations
– Structural equivalence is based on some notion
of meaning behind those declarations
– Name equivalence is more fashionable these
days

Name Equivalence
• There are at least two common variants on
name equivalence
– The differences between all these approaches
boils down to where you draw the line between
important and unimportant differences between
type descriptions
– In all three schemes described in the book, we
begin by putting every type description in a
standard form that takes care of "obviously
unimportant" distinctions like those above

Name Equivalence
• For example, the issue of aliasing. Should aliased
types be considered the same?
• Example:
TYPE cel_temp = REAL;
faren_temp = REAL;
VAR c : cel_temp;
f : faren_temp;
…
f := c; (* should this raise an error? *)
• With strict name equivalence, the above raises an
error. Loose name equivalence would allow it.

Structural Equivalence
• Structural equivalence depends on simple
comparison of type descriptions substitute
out all names
– expand all the way to built-in types
• Original types are equivalent if the
expanded type descriptions are the same

Type Casting
• Most programming languages allow some form of
type conversion (or casting), where the
programmer can change one type of variable to
another.
• We saw a lot of this in Python:
– Every print statement implicitly cast variables to be
strings. We even coded this in our own classes.
– Example from Point class:
def __init__(self):
return ‘<‘ + str(self._x) + ‘,’ + str(self._y) + ‘>’

Type Casting
• Coercion
– When an expression of one type is used in a
context where a different type is expected, one
normally gets a type error
– But what about
var a : integer; b, c :
real;
...
c := a + b;

Type Casting
• Coercion
– Many languages allow things like this, and
COERCE an expression to be of the proper
type
– Coercion can be based just on types of
operands, or can take into account expected
type from surrounding context as well
– Fortran has lots of coercion, all based on
operand type

Type Coercion
• C has lots of coercion, too, but with simpler
rules:
– all floats in expressions become doubles
– short int and char become int in
expressions
– if necessary, precision is removed when
assigning into LHS

Type Checking
• In effect, coercion rules are a relaxation of
type checking.
– Recent thought is that this is probably a bad
idea.
– Languages such as Modula-2 and Ada do not
permit coercions.
– C++, however, goes crazy with them, and they
can be one of the hardest parts of the language
to understand.

Type Checking
• There are some hidden issues in type checking that
we usually ignore.
• For example, consider x + y. If one of them is a
float and one an int, what happens?
– Cast to float. What does this mean for performance?
• What type of runtime checks need to be performed?
Can they be done at compile time? Is precision lost?
• In some ways, there are good reasons to prohibit
coercion, since it allows the programmer to
completely ignore these issues.

Type Checking
• Make sure you understand the difference
between
– type conversions (explicit)
– type coercions (implicit)
– sometimes the word 'cast' is used for
conversions (C is guilty here)

Records (Structures) and
Variants (Unions)
• Records
– usually laid out contiguously
– possible holes for alignment reasons
– smart compilers may re-arrange fields to
minimize holes (C compilers promise not to)
– implementation problems are caused by records
containing dynamic arrays
• we won't be going into that in any detail

Variants (Unions)
• Unions (variant records)
– overlay space
– cause problems for type checking
• Lack of tag means you don't know what is
there
• Ability to change tag and then access fields
hardly better
– can make fields "uninitialized" when tag is
changed (requires extensive run-time support)
– can require assignment of entire variant, as in Ada

Variants (Unions)
• Memory layout and its impact (structures)
Figure 7.1 Likely layout in memory for objects of type element on a 32-bit machine.
Alignment restrictions lead to the shaded “holes.”

Variants (Unions)
Figure 7.2 Likely memory layout for packed element records. The atomic_number and atomic_weight
elds are nonaligned, and can only be read or written (on most machines) via
ﬁ multi-
instruction sequences.

Variants (Unions)
Figure 7.3 Rearranging record elds to minimize holes.
fi By sor ting elds according to
fi
the size of their alignment constraint, a compiler can minimize the space devoted to
holes, while keeping the elds aligned.
fi

Variants (Unions)
• Memory layout and its impact (unions)
Figure 7.15 (CD) Likely memory layouts for element variants. The value of the naturally occurring
eld (shown here with a double border) determines which of the interpretations of the remaining
ﬁ
space is valid. Type string_ptr is assumed to be represented by a (four-byte) pointer to
dynamically allocated storage.

Arrays
• Arrays are the most common and important
composite data types, dating from Fortran
• Unlike records, which group related fields of
disparate types, arrays are usually
homogeneous
• Semantically, they can be thought of as a
mapping from an index type to a component or
element type

Array requirements
• Most languages require that the index be discrete;
some (such as Fortran) require it to be an integer;
some scripting languages even allow non-discrete
types
– With non-discrete, need some kind of mapping such as a
hash table to get into the actual array
• Generally, the element type can be anything, although
some (again such as early Fortran) require it to be a
scalar.
• A slice or section is a rectangular portion of an array
(See figure on next slide.)
– Usually indicated with (i) (eg Fortran and Ada) or [i] (eg C
or Pascal)

Arrays
Figure 7.4 Array slices(sections) in Fortran90. Much like the values in the header of an enumeration-
controlled loop (Section6.5.1), a: b: c in a subscript indicates positions a, a+c, a+2c, ...through b. If a
or b is omitted, the corresponding bound of the array is assumed. If c is omitted, 1 is assumed. It is
even possible to use negative values of c in order to select positions in reverse order. The slashes in
the second subscript of the lower right example delimit an explicit list of positions.

• In C:
char upper[26];
• In Pascal:
Var upper : array [‘a’..’z’] of char;
• In Fortran:
character, dimension (1:26) :: upper
character (26) upper ! shorthand
• Note that in C, we start counting at 0, but that is
NOT true in Fortran.
Arrays: Declaration

• Dimensions, Bounds, and Allocation
– global lifetime, static shape — If the shape of an array is
known at compile time, and if the array can exist
throughout the execution of the program, then the
compiler can allocate space for the array in static global
memory
– local lifetime, static shape — If the shape of the array is
known at compile time, but the array should not exist
throughout the execution of the program, then space can
be allocated in the subroutine’s stack frame at run time.
– local lifetime, shape bound at elaboration time
Arrays

Arrays
Figure 7.6 Elaboration-time allocation of arrays in Ada or C99.

Array layouts
• Contiguous elements (see Figure 7.7)
– column major: A[2,4] is followed by A[3,4]
• only in Fortran
• reason seems to be to accommodate idiosyncrasies of
IBM computer it was created on
– row major: so A[2,4] is followed by A[2,5] in
memory
• used by everybody else
• makes array [a..b, c..d] the same as array [a..b] of array
[c..d]

Arrays
Figure7.7 Row- and column-major memory layout for two-dimensional arrays. In row-major order, the elements of a
row are contiguous in memory; in column-major order, the elements of a column are contiguous. The second cache
line of each array is shaded, on the assumption that each element is an eight-byte oating-point number, that
ﬂ
cache lines are 32 bytes long (a common size), and that the array begins at a cache line boundary. If the
array is indexed from A[0,0] to A[9,9], then in the row-major case elements A[0,4] through A[0,7] share a
cache line; in the column-major case elements A[4,0] through A[7,0] share a cache line.

Array layouts: why we care
• Layout makes a big difference for access
speed - one trick in high performance
computing is simply to set up your code to go
in row major order
• (Bad) Example:
for i = 1 to n
for j = 1 to n
A[j][i] = value

Arrays
• Two layout strategies for arrays (see next
slide):
– Contiguous elements
– Row pointers
• Row pointers
– an option in C
– allows rows to be put anywhere - nice for big arrays on
machines with segmentation problems
– avoids multiplication
– nice for matrices whose rows are of different lengths
• e.g. an array of strings
– requires extra space for the pointers

Arrays
Figure 7.8 Contiguous array allocation v. row pointers in C. The declaration on the left is a true two-
dimensional array. The slashed boxes are NUL bytes; the shaded areas are holes. The declaration on
the right is a ragged array of pointers to arrays of character s. In both cases, we have omitted
bounds in the declaration that can be deduced from the size of the initializer (aggregate). Both data
structures permit individual characters to be accessed using double subscripts, but the memory layout
(and corresponding address arithmetic) is quite different.

Arrays: Address calculations
• Example: Suppose we have a 3d array:
A : array [L1..U1] of array [L2..U2] of array [L3..U3]
of elem;
D1 = U1-L1+1
D2 = U2-L2+1
D3 = U3-L3+1
Let
S3 = size of elem
S2 = D3 * S3 (* size of a row *)
S1 = D2 * S2 (* size of a plane *)
• Then calculating A[i,j,k] each time is:
(Address of A) + (i-L1)*S1 + (j-L2)*S2 + (k-L3)*S3

Arrays
Figure 7.9 Virtual location of an array with nonzero lower bounds. By computing the constant portions of an array index at compile time,
we effectively index into an array whose starting address is offset in memory, but whose lower bounds are all zero.

Arrays
• Example (continued)
We could compute all that at run time, but we can make
do with fewer subtractions:
== (i * S1) + (j * S2) + (k * S3)
+ address of A
- [(L1 * S1) + (L2 * S2) + (L3 * S3)]
The stuff in square brackets is compile-time constant
that depends only on the type of A

Strings
• Strings are really just arrays of characters
• They are often special-cased, to give them
flexibility (like polymorphism
or dynamic sizing) that is not available for
arrays in general
– It's easier to provide these things for strings
than for arrays in general because strings are
one-dimensional and (more important) non-
circular

Sets
• We learned about a lot of possible implementations
• Bit sets are what usually get built into programming
languages
• Things like intersection, union, membership, etc. can be
implemented efficiently with bitwise logical instructions
• Some languages place limits on the sizes of sets to make
it easier for the implementor, since even bit vectors get
large for large sets
– There is really no need for this, since generally these sets are
sparse, so can use hash tables to implement effectively.

Pointers And Recursive Types
• Pointers serve two purposes:
– efficient (and sometimes intuitive) access to
elaborated objects (as in C)
– dynamic creation of linked data structures, in
conjunction with a heap storage manager
• Several languages (e.g. Pascal) restrict
pointers to accessing things in the heap
• Pointers are used with a value model of
variables
– They aren't needed with a reference model, like
Python. Why?

Figure 7.11 Implementation of a tree in Lisp. A diagonal slash through a box indicates a null pointer.
The C and A tags serve to distinguish the two kinds of memory blocks: cons cells and blocks containing
atoms.

Figure 7.12 Typical implementation of a tree in a language with explicit pointers. As in Figure 7.11, a diagonal
slash through a box indicates a null pointer.

Pointers And Recursive Types in C
• C pointers and arrays
int *a == int a[]
int **a == int *a[]
• BUT equivalences don't always hold
– Specifically, a declaration allocates an array if it
specifies a size for the first dimension
– otherwise it allocates a pointer
int **a, int *a[]; pointer to pointer to int
int *a[n]; n-element array of row pointers
int a[n][m]; 2-d array

Pointers And Recursive Types in C
• Given this initialization:
int n;
int *a;
int b[10];
a = b;
• Note that the following are equivalent:
n = a[3];
n = *(a+3);

• Compiler has to be able to tell the size of the
things to which you point
– So the following aren't valid:
int a[][] bad
int (*a)[] bad
– C declaration rule: read right as far as you can
(subject to parentheses), then left, then out a level
and repeat
int *a[n], n-element array of pointers to integer
int (*a)[n], pointer to n-element array of
integers

• Problems with dangling pointers are due
to
– explicit deallocation of heap objects
• only in languages that have explicit deallocation
– implicit deallocation of elaborated objects
• Two implementation mechanisms to catch
dangling pointers
– Tombstones
– Locks and Keys

Figure 7.17 (CD) Tombstones. A valid pointer refers to a tombstone that in turn refers to an object.
A dangling reference refers to an “expired” tombstone.

Figure 7.18 (CD) Locks and Keys. A valid pointer contains a key that matches the lock on an object in
the heap. A dangling reference is unlikely to match.

• Problems with garbage collection
– many languages leave it up to the programmer to
design without garbage creation - this is VERY
hard
– others arrange for automatic garbage collection
– reference counting
• does not work for circular structures
• works great for strings
• should also work to collect unneeded tombstones

• Garbage collection with reference counts
Figure 7.13 Reference counts and circular lists. The list shown here cannot be found via any program
variable, but because it is circular, every cell contains a nonzero count.

• Mark-and-sweep
– commonplace in Lisp dialects
– complicated in languages with rich type structure,
but possible if language is strongly typed
– achieved successfully in Cedar, Ada, Java,
Modula-3, ML
– complete solution impossible in languages that are
not strongly typed
– conservative approximation possible in almost any
language (Xerox Portable Common Runtime
approach)

Figure 7.14 Heap exploration via pointer reversal.

Lists
• A list is defined recursively as either the
empty list or a pair consisting of an object
(which may be either a list or an atom) and
another (shorter) list
– Lists are ideally suited to programming in
functional and logic languages
• In Lisp, in fact, a program is a list, and can extend
itself at run time by constructing a list and executing it
– Lists can also be used in imperative programs

Files and Input/Output
• Input/output (I/O) facilities allow a program to
communicate with the outside world
– interactive I/O and I/O with files
• Interactive I/O generally implies communication
with human users or physical devices
• Files generally refer to off-line storage
implemented by the operating system
• Files may be further categorized into
– temporary
– persistent

chapter 7: DATA TYPES - IN PROGRAMMING LANGUAGES

More Related Content

Similar to chapter 7: DATA TYPES - IN PROGRAMMING LANGUAGES (20)

More from fargovagra (7)

Recently uploaded (20)

chapter 7: DATA TYPES - IN PROGRAMMING LANGUAGES