Feel free to put it on here (or contact me directly if you don't feel comfortable doing it on the forum). Manning have their own proof readers I believe so will be doing that in due course as well, but I'm not complaining if you have noticed some issues (and I'm sure there are plenty).

0.2.1 (35.6): Instead, we’ll focus on a core subset of the language that you’ll find gives you the most effective bang for your investment; where there’s further learnings available that could be worthwhile for you, I’ll point it out.

"You'll now be looking at a blank file in the main panel. Entering any text in here will give you full intellisense and code completion etc. just like inside a full fs file. Start by entering something simple into the REPL:"

I thought that the REPL was the F# Interactive window. In this case, the description that follows (hovering over "text") has no impact in the F# Interactive window, but it does in the newly-added script file. Does a script file qualify as a REPL?

A large majority of what you’ve seen so far is simply “stripping away” a lot of what it turns out are largely unnecessary syntax features of C#, but some elements of the language will have been new to you, such as nested scopes and the lack of support for cyclic dependencies.

Listing 5.2
var i = customer.Withdraw(50); ?
var newBalance = customer.Withdraw(50); ?
? Implicitly typed. Bar returns an int, so i is inferred to be an int.
? Use of intelligent naming to explain intent to the reader.

"You'll now be looking at a blank file in the main panel. Entering any text in here will give you full intellisense and code completion etc. just like inside a full fs file. Start by entering something simple into the REPL:"

I thought that the REPL was the F# Interactive window. In this case, the description that follows (hovering over "text") has no impact in the F# Interactive window, but it does in the newly-added script file. Does a script file qualify as a REPL?

Type annotations in C# and F#
Many C# developers recoil when they see types declared after the name of the value. In fact, most languages outside of C / C++ / Java / C# use this pattern. It’s particularly common in languages like F# where type inference is particularly powerful, or optional type systems like Typescript.

5.4.3 Cyclical Dependencies
Not necessarily a limitation of type inference, but cyclical dependencies are also an enabler for type inference as the compiler uses this “restriction” to make decisions regarding type inference.

I just am not sure what you're trying to tell me here. I thought Cyclical dependencies were disallowed by the compiler... are you explaining another reason why type inference isn't perfect, or...?

"So the call to numbers.Add(10) if used to tell the compiler that the List is of type int."

"In this example, there’s no type specified for output anywhere in the code – so the compiler can’t infer the type of List. In this case, it will simply make the entire createList() function generic!" (underlined should be in 'code' format/font, yes?)

6.4.2 Working with immutable data
"So instead, we create copies of the state with updates applies, and return that back out for the caller to work with; that state may be passed in to other calls that generate new state yet again." ["yet again" seems redundant, yes?]

"This is because the the only values that can affect the result are supplied as input arguments...."

6.4.3 Other benefits of immutable data
"...but there are occasions where simply {by?} making your data read-only, the need to “hide” your data goes away."
"We’ll see more of this later, but one of the other benefits of working {with?} immutable data is that you don’t need to worry about locks within a multi{-?}threaded environment."

7 Expressions and Statements
"Expressions and statements are two aspects of programming that we use often, and generally take for granted. In this lesson: -" {extraneous trailing hyphen crashing your exclusive party}

7.1 What are expressions and statements?
"In a nutshell, that’s it really." {"really" seems redundant}
"But how can we write applications when program flow constructs themselves are an expression?" {mixed plural and singular}

7.3 Making life better through Expressions
"We’ve now split our code into two methods – one which has the single responsibility of generating the description, and the other that uses that calls it and uses the result later on."

7.9 Forcing statement-based evaluation
Cryptic compiler errors
One of the elements of F# 4 that I’m not especially fond of are the error messages that it spits out, which are a throwback to F#’s OCaml roots. {mixing singular & plural}

For example, if you create an if / else expression that returns a string value for the if branch, but forget to handle an else branche, you’ll see an error similar to this:

You saw how expressions in F# are a fundamental feature of the language, whereas statements are shied away from – leading us down the road of writing code in a manner that is less likely to lead to bugs.

9 Shaping data with Tuples
We’ll start this unit by looking at the simplest data structure in F#, the Tuple. In this lesson: -

· You’ll see how Tuples are used within F#
· You’ll understand when to use and not use it
· You’ll see how tuples work together with type inference to enable succinct code
· You’ll see how Tuples relate to the rest of .NET

9.1 Priming exercise – returning data from a method
The following method takes in a string {which?} contains an individuals name e.g. “Isaac Abraham” and splits it out into its constituent parts, returning both the forename and surname.

Very quickly you end up with many different DTOs, all of which are very similar – and probably have to map between them, as C# doesn’t support structural typing i.e. the ability to compare to objects that have the same structure rather than type name.

There’s actually work going {on?} in the C# team to try to improve this in the future for C#.

9.5.1 Tuples and the BCL
One of the nicest parts of F# is for it handles interoperability between F# and C# / VB. There’s plenty to see on this later on in the book, but as an example, we’ll see now how F# uses tuple language support to elegantly remove the for out parameters.

9.5.2 When not to use Tuples
So, whilst tuples are very useful (as we’ll see, they can simplify complicated type signatures), you’ll still need to be think a little about e.g. naming functions that return tuples intelligently so that it’s obvious what the parts of the tuple represent.

10 Shaping data with Records
In the previous lesson, we looked a lightweight, simple data of packaging data pieces together with the Tuple.
...
· You’ll learn how to affect changes to records whilst still retaining immutability
· You’ll see some tips for when working with records.

10.1 Priming exercise – creating an immutable type in C#
Let’s start by continuing where we left off in lesson 8 by describing a situation where Tuples aren’t suitable for exposing data – for example, a public contract of some sort where we want explicit named fields, or somewhere that you need to expose more than just two or three properties.

10.2 POCOs done right - Records in F#
Note that for multiline declarations, just like the rest of the language, you need to all fields start on the same column.
I suggest you allow Visual F# Power Tools {to?} take care of formatting for you...

10.3 Creating Records
Create records in F# is super easy
We’ll cover the most common answer in a later lesson (Discriminated Unions), but the main point is that the type system will not allow you to declare a silently populate only part of a record.