Garbage collection
- Other conundrums:
A type system consists of
Fundamentally, records and structures allow 1) aggregation into a single data structures components of different types and 2) a method of addressing each component of an aggregate
Usually this means 1) simply putting components adjacent to each other in memory, and 2) maintaing an offset for each component
with complex.complicated.deep.stuff do
begin
fieldx := 'STUFF GOES HERE';
fieldy := 'STUFF GOES THERE';
fieldz := 'STUFF GOES EVERYWHERE'
end;A very common composite data structure. Most languages have significant syntactical and semantic support for arrays. Fundmentally, an array takes an index to a value.
Your text takes the approach of treating associative arrays as part of this spectrum of various types of indices; this works well with the subsequent conflation of arrays with functions.
It is popular for programming languages to allow enumerations and ranges to used in an array specfication.
Multi-dimensional array declarations are also common in programming langauges.
While many languages treat strings largely as just an array of characters, some give strings a separate type that allows operations that are not applicable to other arrays.
Generally, most languages give strings a reasonably prominent place, both in syntax and semantics, since string processing is so fundamental to real-world problems.
Pascal was the first language to explicitly have a set type; it overloaded the "+", "*", and "-" operators to support support set union, intersection, and difference.
Generally done as a bit vector for smallish sets, and either the language forbids largish sets, or uses a more sparse approach.
Reclaiming unneeded storage: some languages, like C, leave this task to the programmer; others automate the process with garbage collection.
Failing to reclaim storage creates memory leaks; conversely, freeing storage that is still in use creates dangling references. Freeing already freed storage creates double frees.
"It would never have been a problem in the first place, however, if C had been designed for automatic bounds checks."
Yes, and I would note that it also would not have been as serious a problem had return addresses been kept on a separate stack from activation records; or if there had been hardware support for array boundaries; or a host of other techniques.
Although it's past its utility, the original idea of allowing the programmer to do the pointer arithmetic behind flat array implementation was quite efficient, though modern compilers can usually better a programmer's efforts.
Try this program: test-sizeof.c
Mark-and-sweep, classic three steps:
Implementation issues galore, though, and language implementations planning to use mark-and-sweep should plan on this from the beginning
Stop-and-copy, classic unpredictable time problems (also known as "stop the world" pause problem)
Usually fold compaction into this method
As the text points out, consider equality of s == t expressed as
While the last is clearly problematic (what if s and t contain non-semantically significant bits that are not the same?) the others can be useful measures
And what about assignment? If s := t and t is a large recursive structure, the language might just do a shallow copy of t as a pointer, or maybe it does a deep copy, walking the entire structure of t and creating a fresh copy in s.
Or maybe the language supports both shallow and deep mechanisms.
A type system consists of any built-in types, mechanisms to create new types, and rules for type equivalence, type compatibility, and type inference
A strongly typed language never allows an operation to be applied to an object that does not support it. (However, the notions of strong and weak typing are not universally agreed upon.)
A statically typed language enforces strong typing at compilation time.