Add terms from EoP chapter 1

glossary/eop/README.md

@@ -0,0 +1,8 @@
+# Style guide
+
+- The first line of a definition should be a sentence fragment that defines the term, similar to Swift documentation.
+- Hyperlink only the first use of a term.
+- When an example presented is a counterexample, bold the use of the word **not**. 
+- When a phrase is used as a term, but does not yet have a sufficiently standalone definition to merit its own page, refer to it in _italics_.
+- When a word can be used to describe different ideas in different contexts, number the definitions, and nest the elaborations below. See [[uniquely represented]]. Do not number the definitions if there is only one definition.
+- 

glossary/eop/abstract entity.md

@@ -0,0 +1,5 @@
+An individual thing that is eternal and unchangeable.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/abstract genus.md

@@ -0,0 +1,10 @@
+Describes different [[abstract species]] that are similar in some respect.
+
+# Examples
+
+- Number
+- Binary Operator
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/abstract procedure.md

@@ -0,0 +1,16 @@
+A [[procedure]] parameterized by types and constant values, with requirements on these parameters. 
+
+In C++, we use function templates and function object templates. The parameters follow the `template` keyword and are introduced by `typename` for types and `int` or another integral type for constant values.
+
+Requirements are specified via the `requires` clause, whose argument is an expression built up from constant values, concrete types, formal parameters, applications of type attributes and type functions, [[equality]] on values and types, concepts, and logical connectives.
+
+# Example
+
+```cpp
+template <typename Op>
+	requires(BinaryOperation(Op))
+Domain(Op) square(const Domain(Op)& x, Op op) 
+{
+	return op(x, x);
+}
+```

glossary/eop/abstract species.md

@@ -0,0 +1,7 @@
+Describes common properties of essentially [[equivalent]] [[abstract entity|abstract entities]]. 
+
+An entity belongs to a single species, which provides the rules for its construction or existence. An entity can belong to several genera, each of which describes certain properties.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/address.md

@@ -0,0 +1,4 @@
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.3

glossary/eop/ambiguous.md

@@ -0,0 +1,11 @@
+Describes a [[value type]] if and only if a [[value]] of the type has more than one [[interpretation]].
+
+The negation of ambiguous is _unambiguous_.
+
+# Examples
+
+- A type representing a calendar year over a period longer than a single century as two decimal digits is ambiguous. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.2

glossary/eop/argument.md

@@ -0,0 +1,3 @@
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/assignment.md

@@ -0,0 +1,7 @@
+A [[procedure]] that takes two [[object|objects]] of the same type and makes the first object equal to the second without modifying the second.
+
+The meaning of assignment does not depend on the initial value of the first object.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.5

glossary/eop/attribute.md

@@ -0,0 +1,7 @@
+A correspondence between a [[concrete entity]] and an [[abstract entity]], which describes some property, measurement, or quality of the concrete entity. 
+
+Attributes of a concrete entity can change without affecting its [[identity]].
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/codomain.md

@@ -0,0 +1,5 @@
+The output type of a [[functional procedure]].
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.6

glossary/eop/computational basis.md

@@ -0,0 +1,13 @@
+A finite set of [[procedure|procedures]] for a type that enable the construction of any other procedure on the type. 
+
+A basis is _efficient_ if and only if any procedure implemented using it is as efficient as an equivalent procedure written in terms of an alternative basis. 
+
+- A basis for unsigned k-bit integers providing only zero, equality, and the successor function is not efficient, since the complexity of addition in terms of successor is exponential in k.
+
+A basis is _expressive_ if and only if it allows compact and convenient definitions of procedures on the type. In particular, all the common mathematical operations need to be provided when they are appropriate.
+
+- Subtraction could be implemented using negation and addition, but should be included in an expressive basis. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.4

glossary/eop/concept.md

@@ -0,0 +1,11 @@
+A collection of requirements on a type, expressed as syntactic, semantic, and complexity properties. 
+
+More formally, a description of requirements on one or more types stated in terms of the existence and properties of [[procedure|procedures]], [[type attribute|type attributes]], and [[type function|type functions]] defined on the types.
+
+We say a concept is _modeled_ by specific types, or that the types _model_ the concept, if the requirements are satisfied for these types. 
+
+A program remains correct if a type is replaced by a different type with the same properties; that is, with a type which models the same concept(s).
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.7

glossary/eop/concrete entity.md

@@ -0,0 +1,12 @@
+An individual thing that comes into and out of existence in space and time.
+
+Concrete entities are not only physical entities but also legal, financial, or political entities. 
+
+# Examples
+
+- Socrates 
+- the United States of America
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/concrete genus.md

@@ -0,0 +1,10 @@
+Describes different [[concrete species]] similar in some respect.
+
+# Examples
+
+- Mammal
+- Biped
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/concrete species.md

@@ -0,0 +1,7 @@
+Describes the set of [[attribute|attributes]] of essentially [[equivalent]] [[concrete entity|concrete entities]].
+
+An entity belongs to a single species, which provides the rules for its construction or existence. An entity can belong to several genera, each of which describes certain properties.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/constructor.md

@@ -0,0 +1,4 @@
+A [[procedure]] transforming [[memory]] locations into an [[object]]. 
+
+The possible behaviors range from doing nothing to establishing a complex object [[state]].
+

glossary/eop/datum.md

@@ -0,0 +1,5 @@
+A finite sequence of 0s and 1s.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.2

glossary/eop/default constructor.md

@@ -0,0 +1,5 @@
+A [[constructor]] that takes no arguments and leaves the [[object]] in a [[partially formed]] state.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.5

glossary/eop/definition space.md

@@ -0,0 +1,15 @@
+(For a [[functional procedure]]) is that subset of [[value|values]] for its inputs to which it is intended to be applied.
+
+A functional procedure always terminates on input in its definition space; while it may terminate for input outside its definition space, it may not return a meaningful value.
+
+# Examples
+
+```cpp
+int square(int n) { return n * n; }
+```
+
+While the domain and codomain of `square` are `int`, its definition space is the set of integers whose square is representable by `int`, and its [[result space]] is the set of square integers representable by `int`. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.6

glossary/eop/destructor.md

@@ -0,0 +1,9 @@
+A [[procedure]] causing the cessation of an [[object|object's]] existence. After a destructor has been called on object, no procedure can be applied to it, and its former [[memory]] locations and resources may be reused for other purposes.
+
+The destructor is normally invoked implicitly. 
+
+Global objects are destroyed when the application terminates, local objects are destroyed when the block in which they are declared is exited, and elements of a data structure are destroyed when the data structure is destroyed.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.5

glossary/eop/domain.md

@@ -0,0 +1,7 @@
+The input types of a [[functional procedure]].
+
+Rather than defining the domain of a non-[[homogeneous]] functional procedure as the direct product of its input types, we refer individually to the input types of a procedure.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.6

glossary/eop/equal.md

@@ -0,0 +1,11 @@
+1. Describes two [[value|values]] of a [[value type]] if and only if they [[representation|represent]] the same [[abstract entity]]. 
+
+	Two values are _representationally equal_ if and only if their [[datum|datums]] are identical sequences of 0s and 1s.
+
+2. Describes two [[object|objects]] if and only if their [[state|states]] are equal.
+
+	If two objects are equal, we say one is a _copy_ of the other.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapters 1.2 (Def. 1), 1.3 (Def. 2)

glossary/eop/equality.md

@@ -0,0 +1,7 @@
+A [[procedure]] that takes two [[object|objects]] of the same type and returns true if and only if the object [[state|states]] are [[equal]]. 
+
+Inequality is always defined and returns the negation of equality. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.5

glossary/eop/equivalent.md

@@ -0,0 +1,2 @@
+Note: Used by stepanov in chapter 1.1, not yet defined, but I think it should be. Might need to refer to mathematical literature because stepanov found it unnecessary to define.
+

glossary/eop/function.md

@@ -0,0 +1,10 @@
+A rule that associates one or more [[abstract entity|abstract entities]], called [[argument|arguments]], from corresponding species with an [[abstract entity]], called the [[result]], from another species.
+
+# Examples
+
+- The successor function: associates each natural number with the one that immediately follows it
+- The function that associates with two colors the result of blending them.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/functional procedure.md

@@ -0,0 +1,38 @@
+A [[regular procedure]] defined on [[regular type|regular types]], with one or more direct inputs and a single output that is returned as the result of the procedure. 
+
+The regularity of functional procedures allows two techniques for passing inputs. When the size of the parameter is small or if the procedure needs a copy it can mutate, we pass it [[pass by value|by value]], making a local copy. Otherwise, we pass it by [[pass by constant reference|constant reference]]. A functional procedure can be implemented as a C++ function, function pointer, or function object. 
+
+# Examples
+
+This is a functional procedure:
+
+```cpp
+int plus_0(int a, int b)
+{
+	return a + b;
+}
+```
+
+This is a semantically equivalent functional procedure:
+
+```cpp
+int plus_1(const int& a, const int& b)
+{
+	return a + b;
+}
+```
+
+This is semantically equivalent but is not a functional procedure, because its inputs and outputs are passed indirectly:
+
+```cpp
+void plus_2(int* a, int* b, int* c)
+{
+	*c = *a + *b;
+}
+```
+
+In `plus_2`, `a` and `b` are input objects, while `c` is an output object. The notion of a functional procedure is a syntactic rather than semantic property: In our terminology, `plus_2` is [[regular procedure|regular]] but not [[functional procedure|functional]].
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.6

glossary/eop/homogeneous.md

@@ -0,0 +1,7 @@
+Describes a [[functional procedure]] whose input objects are all the same type.
+
+The [[domain]] of a homogeneous functional procedure is the type of its inputs.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.6

glossary/eop/identity token.md

@@ -0,0 +1,13 @@
+A unique value expressing the [[identity]] of an [[object]] and is computed from the value of the object and the [[address]] of its resources.
+
+Testing equality of identity tokens corresponds to testing identity. During the lifetime of an application, a particular object could use different identity tokens as it moves either within a data structure or from one data structure to another.
+
+# Examples
+
+- The address of the object
+- An index into an array where the object is stored
+- An employee number in a personnel record
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.3

glossary/eop/identity.md

@@ -0,0 +1,7 @@
+Determines the sameness of a thing changing over time. 
+
+Identity is a primitive notion of our perception of reality.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.1

glossary/eop/interpretation.md

@@ -0,0 +1,7 @@
+An entity which corresponds to a particular [[datum]]; the datum is called the [[representation]] of the entity.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.2
+
+> A [[value type]] is a correspondence between a species ([[abstract species|abstract]] or [[concrete species|concrete]]) and a set of [[datum|datums]]. A datum corresponding to a particular entity is called a [[representation]] of the entity; the entity is called the [[interpretation]] of the datum. We refer to datum together with its interpretation as a [[value]].

glossary/eop/memory.md

@@ -0,0 +1,12 @@
+A set of words, each with an [[address]] and a _content_. 
+
+The addresses are values of a fixed size, called the _address length_. The contents are [[value|values]] of another fixed size, called the _word length_. The content of an address is obtained by a _load_ operation. The association of a content with an address is changed by a _store_ operation. 
+
+# Examples
+
+- Bytes in main memory
+- Blocks on a disc drive
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.3

glossary/eop/object type.md

@@ -0,0 +1,11 @@
+A pattern for storing and modifying [[value|values]] in [[memory]]. 
+
+Corresponding to every object type is a value type describing states of objects of that type. Every object belongs to an object type. 
+
+# Examples
+
+- Integers represented in 32-bit two's complement little-endian format aligned to a 4-byte address boundary. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.3

glossary/eop/object.md

@@ -0,0 +1,13 @@
+A [[representation]] of a [[concrete entity]] as a [[value]] in [[memory]]. 
+
+An object has a [[state]] that is a value of some [[value type]]. The state of an object is changeable. Given an object corresponding to a concrete entity, its state corresponds to a [[snapshot]] of that entity. An object owns a set of _resources_, such as memory words or records in a file, to hold its state.
+
+While the value of an object is a contiguous sequence of 0s and 1s, the resources in which those 0s and 1s are stored are not necessarily contiguous. It is the [[interpretation]] that gives unity to an object.
+
+Values and objects play complementary roles. Values are unchanging and are independent of any particular implementation in the computer. Objects are changeable and have computer-specific implementations. 
+
+Objects hold values representing entities. Since objects are changeable, they can represent concrete entities by taking on a new value to represent a change in the entity. Objects can also represent abstract entities: staying constant or taking on different approximations to the abstract. 
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.3

glossary/eop/partially formed.md

@@ -0,0 +1,8 @@
+Describes an [[object]] if it can be [[assignment|assigned]] to or [[destructor|destroyed]]. 
+
+For an object that is partially formed but not [[well formed]], the effect of any [[procedure]] other than assignment (only on the left side) and destruction is not defined.
+
+# Source
+
+[Elements of Programming](http://elementsofprogramming.com/eop.pdf), Chapter 1.5
+