" especially in the programming worls,"
"worls" should be "world"

"Grasp the sense of each rule clerly."
Should be clearly.

5. Typeclasses
   "Key ideas include the following: (1) we will define a safe version of foldr that wil works for any monoid; we’ll see how to associate monoid data (a binary operation, identity element, property proofs) with types, whose values are taken as monoid elements; (4) how to tell Lean to automaticall (implicitly) find and pass monoid data structures to functions depending on the types of other arguments; (5) and ways to use this approach in useful ways."

Should be something like: "Key ideas include the following: (1) we will define a safe version of foldr that will work for any monoid; (2) we’ll see how to associate monoid data (a binary operation, identity element, property proofs) with types, whose values are taken as monoid elements; (3) how to tell Lean to automatically (implicitly) find and pass monoid data structures to functions depending on the types of other arguments; (4) and ways to use this approach in useful ways."

5.1.1. Algebraic Structures
"This chapter will explain how to formalize such structures in Lean, settings patterns for more abstract mathematics as well as for important generalized programming abstractions, as well. For example, we ‘ll see that applicative functor objects extend function application to multiple arguments, and that monads extend function composition to add useful behaviors to it, in turn enabling apparently imperative styles of programming in pure functional languages."

Should be something like: "This chapter will explain how to formalize such structures in Lean, setting patterns for more abstract mathematics as well as for important generalized programming abstractions, as well. For example, we‘ll see that applicative functor objects extend function application to multiple arguments, and that monads extend function composition to add useful behaviors to it, in turn enabling apparently imperative styles of programming in pure functional languages."
I think "settings patterns" is supposed to be "setting patterns", but not 100% sure.

5.1.2. Monoids so far
"Here are examples using these constructs. .First we apply foldr to a monoid α and a list α."

Should be "Here are examples using these constructs. First, we apply foldr to a monoid α and a list α."

5.2. Associating values with types
"We can then use the *+ and * notations to denote whathever operators are recorded in the op field of any given monoid object."

Should be "We can then use the + and * notations to denote whatever operators are recorded in the op field of any given monoid object."

"For this to work (and for some other reasons) we’’ define separate additive and multiplicative monoid types."

Should be: "For this to work (and for some other reasons) we’ll define separate additive and multiplicative monoid types."

5.2.1. Foldr over any monoid
"Finally, given these constraints, we note an real opportunity. "

Should be: "Finally, given these constraints, we note a real opportunity. "

Chapter 2.2

2.2.2

There's a typo here, the comment here should read "return false (ff in Lean)"

def all_false : prop_var → bool
| _ := ff   -- for any argument return true (tt in Lean)

This prop_eval code is a bit confusing potentially. Maybe some more explanation like this would be good

--This function takes in a proposition expression *and* a function called i representing the interpretation of all variables
def prop_eval : prop_expr → (prop_var → bool) → bool
| (var_expr v) i := i v --a variable expression evaluates to just the interpretation of that variable
| (and_expr e1 e2) i := band (prop_eval e1 i) (prop_eval e2 i) --evaluate each part of the and expression individually and then do a boolean and (band) on those values
| (or_expr e1 e2) i := bor (prop_eval e1 i) (prop_eval e2 i) --evaluate each part of the or expression individually and then do a boolean or (bor) on those values

Having no prior experience with lean, I am unfamiliar with its syntax. I would recommend including a link/recommendation to basic lean syntax.
For example, some links that might be helpful include for inductive type declaration:
https://leanprover.github.io/reference/declarations.html#inductive-types
https://leanprover.github.io/theorem_proving_in_lean4/inductive_types.html#:~:text=It%20is%20also%20known%20as,elements%20beyond%20those%20they%20construct.

"This means, among other things, that one can add points to points in tf without receiving any type errors from the programming language system, even though addition of points to points makes no physical sense and is inconsistent with the abstract mathematics of the domain. In an affine space, there is no operation for adding points to point."

This is more of a request for clarification. Does automating this rule of preventing the addition of a point to a point count as automated reasoning?

"First, as mentioned, it substitues concrete representations for abstract, adding inessesntial complexity to models and computations."
Substitues and inessesntial should be substitutes and inessential.

"This is is relevant because it suggests that fully formalizing the fully developed mathematical language of the given domain, we will be well on our way to having reference specifications and with computable implementations."

There are two "is" at the beginning of the sentence.
Also a "by" could be added between "that" and "fully".

Chapter 4

4.3.2

Infix operators/notation not explained before being used at

-- notation, :: is infix for cons

4.3.5. Exercises

Phrasing it as "values greater than 0" may make this proof trickier since Lean's contradiction tactic does not automatically detect 0 > 0 as a contradiction whereas it does detect 0 ≠ 0

Need to use something like gt_irrefl for the function what I can tell which is not something we've talked about . Likewise creating proofs to give the function requires something like nat.le_succ_of_le

4.4.8. Exercises

The map-reduce is a substantial step up from the other exercises. I think it might be better to either remove this one or change it to something that's a little easier to do

4.5. Recursive Proofs

Typo in this paragraph

provide a concrete and pecific example of this reasoning and how we can automate it using tools we already have, concluding what is called the induction axiom for natural numbers (arguments to P);

4.5.1.3. Summary: Proof by Induction

I think the code about factorials was mistakenly placed here or missing an explanation around it

4.5

Proofs about (+) and (*) are often hard to follow in lean due to using not using the kinds of infix operators that we're used to seeing. It might be very helpful to provide comments on each line to show the goal in terms of infix operators

I think it would be good to give some guidance for the mul_distrib_add_nat_left exercise as this was fairly tricky to figure out especially since it's not clear at first what the simp tactic recognizes for nat.add and what it does not

For the foldr' definition here, I think it might make more sense to use id instead of e here for the pattern matching. Using e is explained later in chapter 5, but isn't yet explained here

def foldr' {α : Type} : @monoid α → list α → α
| (monoid.mk op e _ _) l := foldr op e l

4.5.3. Inductive Families

Still shows the coming soon text here

We will mainly use Lean 3, nothwithstaning that Lean 4 is garnering real attention and effort.

The typo "nothwithstaning" should be changed to "notwithstanding".

chapter 5

Think the * needs to be escaped here on this line since it's missing inside of the brakets

and * as a notation for op in a multiplicative monoid, such as ⟨nat, , 1⟩.

Looks like there's a typo on this line:

In practce, Lean provides mechanisms for writing one definition and then cloning it automatically to produce the code for the other.

5.3.6. Example: default typeclass

The solution is already given for the exercise on the notes here. I think that was a mistake?

5.3.8. Typeclass inheritance

Might be good to copy paste the source code definition if this is going to be left in.
The actually types themselves are just Type u -> Type u

"The langauge they define contains all of the strings constructible by any finite number of applications of the defined constructors and no other terms."

"langauge" should be "language"

"we’ll better explain wht it all menas."
Typo, should be "what it all means."

"Our next step toward formalizing abstract mathematics for software engineering, we will specify the syntax and semantics of a simple but important mathatical language, namely propositional logic."

Mathatical should be mathematical, and I believe adding "For" would improve the wording.

"In our next step toward formalizing abstract mathematics for software engineering, we will specify the syntax and semantics of a simple, but important, mathematical language, namely propositional logic."

"We Open the bal namespace so that we don’t have to write bal. before each constructor name."

"Open" should not be capitalized and "bal." doesn't need the "."

"def all_false : prop_var → bool
| _ := ff -- for any argument return true (tt in Lean)"

I believe the comment should be, "for any argument return false (ff in Lean)"

Chapter 3

Overall

Overall notes, the chapter moves through concepts very quickly. I think it needs some deeper explications of each concept before going forward

For something about type universes that may help a bit, one thing I remember about type universes that confused me at the time I learned them was that unlike OOP typing, an object cannot be a member of multiple types

3.4.4.1. Introduction Rules

Lambda expressions are not explained sufficiently before being used here. Would be helpful to describe the syntax here and what it means

2.1.5

Total functions and natural numbers are not defined before they are used. Perhaps this can be rewritten:

In this case, there is total function from terms of type bal to ℕ, so we can specify the semantics as a function in Lean. (All functions in Lean represent total functions in mathematics.)

to be more like this:

In this case, this is a function from terms of type bal to ℕ (positive whole numbers). This is also total because all inputs (the strings) have a defined output (their depth). We can use that to specify the semantics as a function in Lean. (All functions in Lean represent total functions in mathematics)

This paragraph is a little tricky to read without background in lean. This may also be a good place for a visual. I could help create one here if you would like that

The function is defined by case analysis on the argument. If it is the empty string, mk_empty, the function returns 0. Otherwise (the only remaining possibility) is that the value to which sem is applied is of the form (mk_nonempty l b r) where l and r are values representing left and right parenthesis, and where b is some smaller string/value of type bal. In this case, the nesting depth of the argument is one more than the nesting depth of b, which we compute by applying bal recursively to b.

Perhaps something along the lines of:

The function is defined by giving values base on the possible ways the given string could be have been constructed. This is called case analysis. If it is the empty string, mk_empty, the function returns 0 since the empty string has no depth. Otherwise (the only remaining possibility) is that the value was constructed from combined some other string with parenthesis. In our code that means using mk_nonempty l b r where l and r are values representing left and right parenthesis, and where b is some smaller string/value of type bal. In this case, the nesting depth of the argument is one more than the nesting depth of b, so we can compute the depth by applying bal recursively to `b.

Additionally, how would you test the fixing of the bug?

"This is the of abstract specifictions from which concrete implementations are derived."

The typo could be changed by removing "of" and changing it to, "These are the abstract specifications from which concrete implementations are derived.", or something along those lines.

I would suggest that students follow along in VSCode/lean while they read through section 2.1. To do that, I suggest the following links for installing/setting up Lean in VSCode:
https://leanprover.github.io/reference/using_lean.html
https://leanprover-community.github.io/get_started.html

Link(s) for installing and using VSCode could also be added.

• It might be helpful to provide an example use of pEval as students likely don't have lean syntax quite down at this point
• Worth defining what a unary operator is (that it only takes one input rather than two)
• Worth clarifying what is mean by "Add end-to-end support for logical nand (↑) and nor (↓) expression-building operators"

"Perhaps the most fundamental reason is that math has up until recently been a quasi-formal, paper-and-pencil exercise, making it, hard even impossible, to connect code to such mathematics."

Sentence structure might be changed to "Perhaps the most fundamental reason is that math has up until recently been a quasi-formal, paper-and-pencil exercise making it hard, even impossible, to connect code to such mathematics." for clarity.

"The first two axioms that that the and and or operators (∧, ∨) are commutative."
I believe the sentence should be "The first two axioms are that the and and or operators (∧, ∨) are commutative.". Not sure if this is the intended meaning.

When discussing affine spaces, tensor fields, and topological manifolds, the examples go over my head. I don't know if I should know these terms or if I haven't taken classes yet that go into these terms, but affine spaces are used again in 1.1.2. and I realized that I wasn't familiar with the term affine spaces. Maybe a small, quick definition in the beginning would help? Not completely sure.

For 2.7.1, it might be helpful to take some of the theorems in section 2.7.1 and have a checkpoint exercise just to make sure students understand the material by leaving blanks or chunks of some of the latter theorems to fill out. By leaving different parts of a theorem for students to fill out, students can ask for help on specific parts of the theorems based on what they got wrong/incorrect.

4.2.2. Operations:
"When proving function or other data type, however, the particular value of the type that you construct is usually important. "
I believe it should be something like "When proving a function or another data type, however, the particular value of the type that you construct is usually important. "

4.3.1. Data Type
"The list data type is surprising similar to the nat data type. Where as a larger nat is constructed from only a smaller nat, a larger list is constructed from a new first element (the head of the new list) and a smaller list (the tail of the new list)."
Should be "The list data type is surprisingly similar to the nat data type. Whereas a larger nat is constructed from only a smaller nat, a larger list is constructed from a new first element (the head of the new list) and a smaller list (the tail of the new list)."

4.3.4. Partial Functions
"Let’s see some fo the solutions that are available."
Should be "Let’s see some of the solutions that are available."

4.3.4.2. Option values
"The next solution changes the type of the function, so that return value is in the form of a variant type, a value of which is either none or some valid return value."
Should be something like "The next solution changes the type of the function, so that the return value is in the form of a variant type, a value of which is either none or some valid return value."

4.3.4.3. Precondition
"Let’s see how e might first write the function using a tactic script, to take advantage of your familiarity with using it to build proofs."
Should be "Let’s see how be might first write the function using a tactic script, to take advantage of your familiarity with using it to build proofs."

4.4.3. Map
"Of course well run into exactly the same sort of problem, of having to engage in error-prone cloning and editing of code, if we want to now map lists of Boolean values to lists of strings (e.g., mapping each tt to “T” and each ff to “F”).
And you can imagine many other examples: mapping lists of employees to list of their corresponding salaries, or mapping lists of Boolean values to lists of their negations, etc. "
Should be "Of course we'll run into exactly the same sort of problem, of having to engage in error-prone cloning and editing of code, if we want to now map lists of Boolean values to lists of strings (e.g., mapping each tt to “T” and each ff to “F”).
And you can imagine many other examples: mapping lists of employees to lists of their corresponding salaries, or mapping lists of Boolean values to lists of their negations, etc.
"

"The answer should now we pretty clear:"
Should be "The answer should now be pretty clear:"

4.5. Recursive Proofs
"provide a concrete and pecific example of this reasoning and how we can automate it using tools we already have, concluding what is called the induction axiom for natural numbers (arguments to P);"
Should be "provide a concrete and specific example of this reasoning and how we can automate it using tools we already have, concluding what is called the induction axiom for natural numbers (arguments to P);"

4.5.1. The Idea by Example
"The simp tactict tries to find, and if found applies, rules/axioms from the definition of the listed functions: here from just nat.add."
Should be "The simp tactic tries to find, and if found applies, rules/axioms from the definition of the listed functions: here from just nat.add."

4.5.1.2. A Solution
"From a proof that 0 is a left identity for 0 can we build a proof that 0 is a left identity for one!"
Should be "From a proof that 0 is a left identity for 0 we can build a proof that 0 is a left identity for one!"

4.5.1.8. Monoids and Foldr
"We can now define a general structure that we can instantiate to formally represent either and additive or a multiplicative monoid on the natural numbers."
Should be "We can now define a general structure that we can instantiate to formally represent either an additive or a multiplicative monoid on the natural numbers."

4.5.2.2. Induction Axiom for Lists
"We see again that there’s nothing myseterious about proof by induction."
Should be "We see again that there’s nothing mysterious about proof by induction."

"Every inductive axiom can be understood as a proof of universal generalization that asserts that every value of some input type has a corresponging result value of type."
Should be "Every inductive axiom can be understood as a proof of universal generalization that asserts that every value of some input type has a corresponding result value of type."

"In the style of the preceding examples, give formal proofs of that the remaining inference rules are valid in our own model of propositional logic."

I believe that the "of" after "formal proofs" can be eliminated.

"To get you started, the following proof shosws that the false elimination inference rule is valid in our logic. "
"shosws" should be "shows"

Typo on "in" at this sentence:

To illustrate the point, n this chapter we add a fourth section

Involute was not defined in 2.5.5 before the example was given there, so it would be good to add a definition before that

"This chapter pulls together in one place a formal validation of the claim that our model of propositional logic satisfies all of the =inference rules of that logic."

Extra "=" that shouldn't be there

Possible terms to remove or de-emphasize?

• context-free grammars

Writing Clarification Suggestions

2.1.3

Clarifying this paragraph

We’ll start by defining separate data types (each with just one value) to represent left and right parentheses, respectively. The names of the types are lparen and rparen. Each has a single value that we will call mk. We can use qualified names to distinguish these values: lparen.mk and rparen.mk.

To something more like

We’ll start by defining two data types. The names of the types are lparen and rparen. We use these to represent left and right parentheses, respectively. Each holds a single value inside it that we will label as mk. We can use qualified names to distinguish between the two types' differing mk values: lparen.mk and rparen.mk.

Clarifying this sentence

Second, if b is any balanced string, then the term mk_nonempty l b r is also (that is also represents) a balanced string, namely (b)

to something along the lines of

Second, if b is any balanced string, then the term mk_nonempty l b r is also a balanced string. What that represents is taking the existing string b and combining it with a left parenthesis l and a right parenthesis r. In other words, it represents turning b into (b)

2.6.2.1

Typo here with "sucg" instead of "such"

The standard notation for sucg a “meaning-of” operator is a pair of denotation or Scott brackets.

2.6.2.3

Might be helpful to first show the proof without the repeat and then show how long it is followed by showing how using repeat makes it much shorter. That would likely help student s get a better sense of why repeat is useful here and what is going on in the proof here as they can't step through each loop of the repeat

"To begin, we define a datatype the values of which will represent our the variables."

I believe removing "the" before variables would help the wording

"To begin, we define a datatype the values of which will represent our variables."

"In Lean, types are terms, too, and so they have types, as we have already seen. So what is the type of 1 = 1. It’s Prop."

I believe a question mark would work better for the "So what is the type of 1=1" sentence, like so: "In Lean, types are terms, too, and so they have types, as we have already seen. So what is the type of 1 = 1? It’s Prop."

"We we have the following picture of the type hierarchy for the terms we’ve just constructed."
One of the "we" should be deleted.