Fix IMMEDIATE bugs and typos from REVIEW-20260424b

- ch20: fix missing ');' closing forEachRemaining lambda call (Java code bug)
- ch20: fix 'ccoverageExcludedPackages' -> 'coverageExcludedPackages' (sbt setting typo)
- ch20: fix 'meaasure' -> 'measure'
- ch40: fix 'aimed at primarily at' -> 'aimed primarily at' (both occurrences)
- ch40: fix 'undergradutes' -> 'undergraduates' (both occurrences)
- ch50: fix 'feautures' -> 'features'
- ch50: fix 'intutive' -> 'intuitive'
- ch50: fix double period '..' -> '.'
- ch60: fix 'anguage' -> 'language'

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: klaeufer

source/20-imperative.rst

@@ -201,7 +201,7 @@ In Java, we can use a `Scanner` with a custom delimiter to split input into word
     if (!word.isEmpty()) {
       freq.put(word, freq.getOrDefault(word, 0) + 1);
     }
-  }
+  });
 
   for (var entry : freq.entrySet()) {
     System.out.println(entry.getKey() + ": " + entry.getValue());
@@ -383,7 +383,7 @@ Measuring code coverage
 ```````````````````````
 
 The *code coverage* of your tests indicates how thoroughly you're testing.
-Typically, you would use the `sbt scoverage plugin <https://github.com/scoverage/sbt-scoverage>`_ to meaasure what percentage of your main code are covered by your tests.
+Typically, you would use the `sbt scoverage plugin <https://github.com/scoverage/sbt-scoverage>`_ to measure what percentage of your main code are covered by your tests.
 
 .. code-block:: bash
 
@@ -419,7 +419,7 @@ If your coverage percentages appear low, you can make them more accurate by excl
 
 .. code-block:: scala
 
-  ccoverageExcludedPackages := """.*\.simple\..*;.*\.common.*;.*\.Main;benchmark\..*"""
+  coverageExcludedPackages := """.*\.simple\..*;.*\.common.*;.*\.Main;benchmark\..*"""
 
 Additional information on testing is available in the corresponding section of the `COMP 335/435: Formal Methods lecture notes <https://lucformalmethodscourse.github.io/30-testing.html>`_.
 

source/40-functional.rst

@@ -897,7 +897,7 @@ For more details on space complexity and tail recursion, please take a look at t
 Separation of concerns at the type level
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. note:: This section is aimed at primarily at graduate students, but advanced undergradutes are encouraged to work through it as well.
+.. note:: This section is aimed primarily at graduate students, but advanced undergraduates are encouraged to work through it as well.
 
 The overall approach is to separate recursion from structure by formalizing algebraic data types as initial F-algebras.
 
@@ -1072,7 +1072,7 @@ Some of our examples include implementations of ``traverse``.
 Other useful abstractions
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. note:: This section is aimed at primarily at graduate students, but advanced undergradutes are encouraged to work through it as well.
+.. note:: This section is aimed primarily at graduate students, but advanced undergraduates are encouraged to work through it as well.
 
 In this section, we will discuss a few more useful yet relatively simple abstractions.
 

source/50-representationinterpretation.rst

@@ -244,7 +244,7 @@ Our language has the following features:
 
 
 
-The syntactic feautures of our language are captured by the following grammar. For motivation, the sort of program that we are interested is exemplified by::
+The syntactic features of our language are captured by the following grammar. For motivation, the sort of program that we are interested is exemplified by::
 
     StudentCourseRecord = record
         int firstExamScore;
@@ -322,7 +322,7 @@ Statements are given by the BNF grammar::
      	|	while (e) do S
 
 
-We first formalize the intutive execution semantics of the toy language. As before, the point of doing this is to present the basic ideas in the interpreter without getting tied up in the programming details of the interpreter. In any case, these details are presented later in this lecture. In particular, in this initial first cut, we will begin by ignoring declarations. Also, in this new presentation, we extend the memory store to map identifiers not only to integer variable objects but also to record objects, each of which maps field names to their corresponding variable objects.
+We first formalize the intuitive execution semantics of the toy language. As before, the point of doing this is to present the basic ideas in the interpreter without getting tied up in the programming details of the interpreter. In any case, these details are presented later in this lecture. In particular, in this initial first cut, we will begin by ignoring declarations. Also, in this new presentation, we extend the memory store to map identifiers not only to integer variable objects but also to record objects, each of which maps field names to their corresponding variable objects.
 
 Recall that we viewed variables as objects with two capabilities:
 
@@ -346,7 +346,7 @@ These evaluation rules are written out precisely in the following picture.
 
 .. image:: images/records3.png
 
-Our earlier rules for evaluating R-values are presented again below..
+Our earlier rules for evaluating R-values are presented again below.
 
 - Evaluating an L-value. In our setup, every L-value (say l) is a variable object that is obtained from the store M. Execute l.get() to compute the return value. This rule subsumes the earlier case for variables.
 - Evaluating e1 + e2: Evaluate e1 first, say to yield value v1. Evaluate e2 next, say to yield value v2. The required result is v1 + v2.

source/60-concurrency.rst

@@ -433,7 +433,7 @@ This gives rise to several conflicting design forces:
 Specific concurrency mechanisms
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Several specific concurrency mechanisms can come as anguage constructs, patterns, and other building blocks:
+Several specific concurrency mechanisms can come as language constructs, patterns, and other building blocks:
 
 - threads (familiar from 313/413)
 - monitors: synchronized/locks, wait/notify