From 09c957bef7b063353add3c04a9e0568aeed1eb30 Mon Sep 17 00:00:00 2001 From: Adriaan Moors Date: Tue, 11 Mar 2014 17:48:36 -0700 Subject: github markdown: use ###### for definitions and notes --- 05-types.md | 36 ++++++------- 07-classes-and-objects.md | 101 +++++++++++++++++------------------- 09-implicit-parameters-and-views.md | 30 ++++------- 14-the-scala-standard-library.md | 3 -- 4 files changed, 77 insertions(+), 93 deletions(-) diff --git a/05-types.md b/05-types.md index 294b87a71d..876d8eea15 100644 --- a/05-types.md +++ b/05-types.md @@ -933,10 +933,10 @@ i.e.\ it is transitive and reflexive. _least upper bounds_ and _greatest lower bounds_ of a set of types are understood to be relative to that order. - -> **Note**: The least upper bound or greatest lower bound -> of a set of types does not always exist. For instance, consider -> the class definitions +###### Note +The least upper bound or greatest lower bound +of a set of types does not always exist. For instance, consider +the class definitions ``` class A[+T] {} @@ -944,20 +944,20 @@ class B extends A[B] class C extends A[C] ``` -> Then the types `A[Any], A[A[Any]], A[A[A[Any]]], ...` form -> a descending sequence of upper bounds for `B` and `C`. The -> least upper bound would be the infinite limit of that sequence, which -> does not exist as a Scala type. Since cases like this are in general -> impossible to detect, a Scala compiler is free to reject a term -> which has a type specified as a least upper or greatest lower bound, -> and that bound would be more complex than some compiler-set -> limit [^4]. -> -> The least upper bound or greatest lower bound might also not be -> unique. For instance `A with B` and `B with A` are both -> greatest lower of `A` and `B`. If there are several -> least upper bounds or greatest lower bounds, the Scala compiler is -> free to pick any one of them. +Then the types `A[Any], A[A[Any]], A[A[A[Any]]], ...` form +a descending sequence of upper bounds for `B` and `C`. The +least upper bound would be the infinite limit of that sequence, which +does not exist as a Scala type. Since cases like this are in general +impossible to detect, a Scala compiler is free to reject a term +which has a type specified as a least upper or greatest lower bound, +and that bound would be more complex than some compiler-set +limit [^4]. + +The least upper bound or greatest lower bound might also not be +unique. For instance `A with B` and `B with A` are both +greatest lower of `A` and `B`. If there are several +least upper bounds or greatest lower bounds, the Scala compiler is +free to pick any one of them. [^4]: The current Scala compiler limits the nesting level diff --git a/07-classes-and-objects.md b/07-classes-and-objects.md index 392da29d0f..46581df80b 100644 --- a/07-classes-and-objects.md +++ b/07-classes-and-objects.md @@ -185,23 +185,24 @@ on base classes forms in general a directed acyclic graph. A linearization of this graph is defined as follows. -> Let $C$ be a class with template -> `$C_1$ with ... with $C_n$ { $\mathit{stats}$ }`. -> The _linearization_ of $C$, $\mathcal{L}(C)$ is defined as follows: -> -> $\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1)$ -> -> Here $\vec{+}$ denotes concatenation where elements of the right operand -> replace identical elements of the left operand: -> -> ``` -> \[ -> \begin{array}{lcll} -> \{a, A\} \;\vec{+}\; B &=& a, (A \;\vec{+}\; B) &{\bf if} \; a \not\in B \\ -> &=& A \;\vec{+}\; B &{\bf if} \; a \in B -> \end{array} -> \] -> ``` +###### Definition: linearization +Let $C$ be a class with template +`$C_1$ with ... with $C_n$ { $\mathit{stats}$ }`. +The _linearization_ of $C$, $\mathcal{L}(C)$ is defined as follows: + +$\mathcal{L}(C) = C, \mathcal{L}(C_n) \; \vec{+} \; \ldots \; \vec{+} \; \mathcal{L}(C_1)$ + +Here $\vec{+}$ denotes concatenation where elements of the right operand +replace identical elements of the left operand: + +``` +\[ +\begin{array}{lcll} +\{a, A\} \;\vec{+}\; B &=& a, (A \;\vec{+}\; B) &{\bf if} \; a \not\in B \\ + &=& A \;\vec{+}\; B &{\bf if} \; a \in B +\end{array} +\] +``` ###### Example @@ -223,10 +224,10 @@ Then the linearization of class `Iter` is Note that the linearization of a class refines the inheritance relation: if $C$ is a subclass of $D$, then $C$ precedes $D$ in any linearization where both $C$ and $D$ occur. -\ref{def:lin} also satisfies the property that a linearization -of a class always contains the linearization of its direct superclass -as a suffix. For instance, the linearization of -`StringIterator` is +[Linearization](#definition-linearization) also satisfies the property that +a linearization of a class always contains the linearization of its direct superclass as a suffix. + +For instance, the linearization of `StringIterator` is ``` { StringIterator, AbsIterator, AnyRef, Any } @@ -245,9 +246,7 @@ which is not a suffix of the linearization of `Iter`. ### Class Members - -A class $C$ defined by a template -`$C_1$ with $\ldots$ with $C_n$ { $\mathit{stats}$ }` +A class $C$ defined by a template `$C_1$ with $\ldots$ with $C_n$ { $\mathit{stats}$ }` can define members in its statement sequence $\mathit{stats}$ and can inherit members from all parent classes. Scala adopts Java and C\#'s conventions for static overloading of @@ -257,19 +256,18 @@ member of a class $C$ overrides a member of a parent class, or whether the two co-exist as overloaded variants in $C$, Scala uses the following definition of _matching_ on members: -> **Definition** -> A member definition $M$ _matches_ a member definition $M'$, if $M$ -> and $M'$ bind the same name, and one of following holds. -> -> 1. Neither $M$ nor $M'$ is a method definition. -> 2. $M$ and $M'$ define both monomorphic methods with equivalent argument -> types. -> 3. $M$ defines a parameterless method and $M'$ defines a method -> with an empty parameter list `()` or _vice versa_. -> 4. $M$ and $M'$ define both polymorphic methods with -> equal number of argument types $\overline T$, $\overline T'$ -> and equal numbers of type parameters -> $\overline t$, $\overline t'$, say, and $\overline T' = [\overline t'/\overline t]\overline T$. +###### Definition: matching +A member definition $M$ _matches_ a member definition $M'$, if $M$ +and $M'$ bind the same name, and one of following holds. + +1. Neither $M$ nor $M'$ is a method definition. +2. $M$ and $M'$ define both monomorphic methods with equivalent argument types. +3. $M$ defines a parameterless method and $M'$ defines a method + with an empty parameter list `()` or _vice versa_. +4. $M$ and $M'$ define both polymorphic methods with + equal number of argument types $\overline T$, $\overline T'$ + and equal numbers of type parameters + $\overline t$, $\overline t'$, say, and $\overline T' = [\overline t'/\overline t]\overline T$.