family_tree: fix wikipedia links

[lambda.git] / family_tree_of_functional_programming_languages.mdwn

diff --git a/family_tree_of_functional_programming_languages.mdwn b/family_tree_of_functional_programming_languages.mdwn
index 90db24e..0086483 100644 (file)
--- a/family_tree_of_functional_programming_languages.mdwn
+++ b/family_tree_of_functional_programming_languages.mdwn
@@ -12,9 +12,9 @@ typed and those that are statically typed.
 
 The **dynamically typed** languages give types more of a background role in the
 program. They include the Lisp family (which in turn includes all the variants
 
 The **dynamically typed** languages give types more of a background role in the
 program. They include the Lisp family (which in turn includes all the variants

-of [[!wikipedia Scheme]], and also [[!wikipedia Common Lisp]], and [[!wikipedia
-Clojure]]). They also include [[!wikipedia Erlang]] and [[!wikipedia Joy]] and
-[[!wikipedia Pure]], and others.
+of [[!wikipedia Scheme (programming language) desc="Scheme"]], and also [[!wikipedia Common Lisp]], and [[!wikipedia
+Clojure]]). They also include [[!wikipedia Erlang (programming language) desc="Erlang"]] and [[!wikipedia Joy (programming language) desc="Joy"]] and
+[[!wikipedia Pure (programming language) desc="Pure"]], and others.

 
 Although these languages are hospitable to functional programming, some of them
 also permit you to write *imperatival* code (that is, code with *side-effects*)
 
 Although these languages are hospitable to functional programming, some of them
 also permit you to write *imperatival* code (that is, code with *side-effects*)


@@ -99,15 +99,15 @@ the seminar.
 
 Most programming languages, functional or not, use **strict/eager evaluation**. For
 instance, languages of the ML family are all statically-typed functional
 
 Most programming languages, functional or not, use **strict/eager evaluation**. For
 instance, languages of the ML family are all statically-typed functional

-languages with strict/eager evaluation. These include [[!wikipedia SML]] and
+languages with strict/eager evaluation. These include [[!wikipedia Standard ML desc="SML"]] and

 [[!wikipedia Caml]] and [[!wikipedia Nemerle]]. Other statically-typed
 [[!wikipedia Caml]] and [[!wikipedia Nemerle]]. Other statically-typed

-functional languages with strict/eager evaluation are [[!wikipedia Scala]] and
+functional languages with strict/eager evaluation are [[!wikipedia Scala (programming language) desc="Scala"]] and

 [[!wikipedia Coq]]. Like Scheme, many of these languages permit *imperatival*
 as well as functional coding; but they are regarded as functional programming
 languages because they are so hospitable to functional programming, and give it
 a central place in their design.
 
 [[!wikipedia Coq]]. Like Scheme, many of these languages permit *imperatival*
 as well as functional coding; but they are regarded as functional programming
 languages because they are so hospitable to functional programming, and give it
 a central place in their design.
 

-A few languages such as [[!wikipedia Miranda]] and [[!wikipedia Haskell]] are
+A few languages such as [[!wikipedia Miranda (programming language) desc="Miranda"]] and [[!wikipedia Haskell (programming language) desc="Haskell"]] are

 statically-typed languages that instead mostly use **lazy evaluation**. However,
 it'd be more strictly accurate to say Haskell is lazy *by default*. You can
 also make Haskell evaluate some expressions strictly/eagerly; you just have to
 statically-typed languages that instead mostly use **lazy evaluation**. However,
 it'd be more strictly accurate to say Haskell is lazy *by default*. You can
 also make Haskell evaluate some expressions strictly/eagerly; you just have to


@@ -126,3 +126,9 @@ imperatival code.)
 We'll talk much more about monads, lazy vs strict evaluation, and functional vs
 imperatival code as we proceed.
 
 We'll talk much more about monads, lazy vs strict evaluation, and functional vs
 imperatival code as we proceed.
 

+We won't much discuss static vs dynamic typing; this has to do with lower-level
+implementation details than we'll be concerned with. However, you'll encounter
+the difference in practice as you work with Scheme and OCaml, respectively; and
+you'll see it referred to as you read around. So it's good for you to
+have placed it in your mental map.
+