Generics terminology (#447)

To talk about generics as a programming language feature, you need a lot of
specialized terminology. We need to agree on the words we are using and their
meaning before we can meaningfully talk about the design of the feature itself.

There a number of problems a glossary solves:

Not everyone knows every term, so having a single place to look them up will
improve the ease of understanding, ease of contributing, and accessibility
of the project.
There may not be widespread agreement on the meaning of some terms. In
particular, individual programming languages tend to assign very specific
meanings to terms used within their ecosystem.
Some terms may be used in multiple ways, but we only use the term with one
specific meaning.
Some terms are our invention and we need to introduce them.


Co-authored-by: Richard Smith <[email protected]>

docs/design/generics/README.md

@@ -12,6 +12,7 @@ feature of Carbon:
 -   ~~Overview~~ - not implemented yet
 -   [Goals](goals.md) - The motivation and principles guiding the design
     direction.
--   ~~Terminology~~ - not implemented yet
+-   [Terminology](terminology.md) - A glossary establishing common terminology
+    for describing the design.
 -   ~~Detailed design~~ - not implemented yet
 -   ~~Rejected alternatives~~ - not implemented yet

docs/design/generics/goals.md

@@ -12,7 +12,6 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 
 -   [Purpose of this document](#purpose-of-this-document)
 -   [Background](#background)
-    -   [Definition of generics](#definition-of-generics)
     -   [Generic parameters](#generic-parameters)
     -   [Interfaces](#interfaces)
     -   [Relationship to templates](#relationship-to-templates)
@@ -52,36 +51,25 @@ forward-looking.
 
 ## Background
 
-### Definition of generics
+Carbon will support
+[generics](terminology.md#generic-versus-template-parameters) to support generic
+programming by way of
+[parameterization of language constructs](terminology.md#parameterized-language-constructs)
+with [early type checking](terminology.md#early-versus-late-type-checking) and
+[complete definition checking](terminology.md#complete-definition-checking).
 
-**TODO** This should be replaced with a link to a terminology doc, once that is
-accepted.
-
-C++ supports
-[parametric polymorphism](https://en.wikipedia.org/wiki/Parametric_polymorphism)
-and [generic programming](https://en.wikipedia.org/wiki/Generic_programming)
-through templates. Templates use
+This is in contrast with the
 [compile-time duck typing](https://en.wikipedia.org/wiki/Duck_typing#Templates_or_generic_types)
-to decide whether arguments are valid. This is a form of
-[structural typing](https://en.wikipedia.org/wiki/Structural_type_system) that
-is usage based.
-
-Carbon will support _generics_ in order to allow definition checking in generic
-programming. Definition checking is accomplished by using
-[bounded parametric polymorphism](https://en.wikipedia.org/wiki/Parametric_polymorphism#Bounded_parametric_polymorphism)
-instead of compile-time duck typing. This means the legal arguments and the
-legal uses of a parameter are both goverened by explicit bounds on the parameter
-in a generic function's signature.
-
-This would be _in addition_ to
+approach of C++ templates, and _in addition_ to
 [template support in Carbon](#relationship-to-templates), if we decide to
 support templates in Carbon beyond interoperability with C++ templates.
 
 ### Generic parameters
 
 Generic functions and generic types will all take some "generic parameters",
-which will frequently be types, and in some cases will be implicit or inferred
-from the types of the values of explicit parameters.
+which will frequently be types, and in some cases will be
+[implicit or inferred](terminology.md#implicit-parameter) from the types of the
+values of explicit parameters.
 
 If a generic parameter is a type, the generic function's signature can specify
 constraints that the caller's type must satisfy. For example, a resizable array
@@ -97,13 +85,13 @@ the same type.
 
 We need some way to express the constraints on a generic type parameter. In
 Carbon we express these "type constraints" by saying we restrict to types that
-implement specific _interfaces_. Interfaces describe an API a type could
-implement; for example, it might specify a set of functions, including names and
-signatures. A type implementing an interface may be passed as a generic type
-argument to a function that has that interface as a requirement of its generic
-type parameter. Then, the functions defined in the interface may be called in
-the body of the function. Further, interfaces have names that allow them to be
-reused.
+implement specific [_interfaces_](terminology.md#interface). Interfaces describe
+an API a type could implement; for example, it might specify a set of functions,
+including names and signatures. A type implementing an interface may be passed
+as a generic type argument to a function that has that interface as a
+requirement of its generic type parameter. Then, the functions defined in the
+interface may be called in the body of the function. Further, interfaces have
+names that allow them to be reused.
 
 Similar compile-time and run-time constructs may be found in other programming
 languages: