What do you think about the draft? How far are you in? What’s working and what can be improved?
Is this a right place to report typos? Or have separate topic?
about your porgress with the book,
Welcome, @gmarik! I think that’s a perfect place for something like this. We can split this thread later, if it grows too long.
1 Like
p12:s/Comapre/Compare/
Comapre var
p27, broken formatting:
class If implements AST { constructor(public conditional:
p37:s/sourde/source/
does not advance the sourde
1 Like
Thanks, @gmarik! Keep 'em coming! I have used Grammarly on the draft, but it can’t catch them all.
1 Like
You are progressing quickly! What are you thoughts so far?
I like it so far.
It’s both terse and informative enough for a beginner like myself. It doesn’t go into rabbit-holes attempting to explain all the terminology and keeps introducing required concepts without overwhelming me.
But someone else’s experience may be different.
Some confusing bits:
Another way to define a function is by writing a so-called arrow function, (…)
Variables are bound with var ,let(and const).
Those 2 paragraphs are unrelated since they’re introducing different concepts(functions and then variables) but for a second i was confused thinking how variables binding relates to the functions.
So maybe structural separation with headers or different wording to make sure those are not explaining same topic.
Minor problem, but may improve clarity.
Say, you want to add a parameter p to a call, given some existing call myCall? We can construct this new call, by quer- ing myCall for its callee and arguments fields:
new Call(myCall.callee, [new Id(“p”), …myCall.args])
It’s confusing, because it’s not tied to the example provided before, and “myCall” has not been introduced.
Also, what’s ‘’myCall.callee”?
Parser-combinators
are pretty easy to follow, which is great, though i feel need/urge for hands-on implementing them to build up the intuition.
As the book recommends, i’ll read through the part 1 before any coding.
Even though I had an idea about parser-combinators, I never read anything about them, so, it’s a pretty good intro, if you ask me, though it could be a book of its own i’m sure.
1 Like
5.1 tokenization
This is all to say that we won’t use a lexer: our parser will be scaner- less.
looks like magic to me at this point of reaching the section, since I assumed there’s always a lexer.
edit:
PEG notation is a good fit for us because it’s designed for scanerless, greedy, back- tracking parsers, and can express prioritized choice.
Ah, that explains it.
I have reworded the part about variables, and removed the myCall examples completely: I think it’s too early in the book.
I went a bit back-and-forth between using the lexer or not when developing the book. I will probably publish my initial lexer as a blog post. However, doing the lexer-less approach required much less code, so I went with it.
I’ve extended the paragraph:
This is all to say that we won’t use a lexer: our parser will be scanerless.
The way to think about scanerless parsing is you treat each character as a token.
However, we will still use the word token when we talk about parsing single logical lexical elements.
1 Like
Page 12, there’s a becuase.
We’ll be only using let in the compiler code, however, var needs mentioning becuase it is var that we will implement for the baseline language.
Also perhaps it should read We’ll only be using.
1 Like
Something that I found odd: On page 13, you show how to define a class called Pair but when you show the new keyword, you create an object from the Point class. Then you proceed to work with Pair.
Yep, should be Pair, instead. I started out with a Point example, but didn’t rename all instances.
1 Like
Page 23, multiplication is written as multiplication ( + ), (Uses the + symbol.).
1 Like
It took me more time to understand section 5.5 compared to what I read so far. I think there’s a transition missing between the regexp combinator and the hello example. Also it might have been nice to show an example of what it parses. hello1 for example. The last paragraph’s structure seemed muddy to me.
1 Like
I have uploaded these changes in a new draft. It should be dated July 13. The way I understand it works, they will be available by using the same download link you already have. I didn’t want to send an email update to everyone about these minor changes.
Also, haven’t addressed the regexp example, yet. Perhaps a hello1 parsing example should do…
Hi, reading the book now!
Page 11: typo: “tripple” -> should be “triple”
More typos and suggestions:
page 9: “The next chapter,TypeScript Basics, gives”; add comma
page 16: The assembly language is a textual representation -> An assembly language…
page 16: “straightforward” doesn’t need a hyphen
page 17: is it better to say “compilation is structured into passes”?
page 18: “an array-like representation is due” -> maybe “appropriate” or “ideal” as opposed to “due”
page 19: Abstract syntax trees ,or ASTs, are the central concept in compilers. ASTs are data structures.
“It’s a tree, that…” comma can be omitted.
It may be a good idea to give a high-level definition of syntax since you use it here a few times, unless you expect readers to already understand it.
page 19: “Here is the graphical representation of the same tree:” but the tree is actually on the next page and text immediately follows the sentence
page 20: It may be better to write “ASTs” since you’re describing the set of them; “AST makes it convenient…” sounds like a particular tree, not the set of them. I would rewrite the sentence as “It’s convenient to operate on ASTs”
page 21: * interfaces, * abstract classes, * union types -> what do the asterisks mean? Are they TypeScript features or a wildcard?
page 21: “because it will clash with JavaScript built-in…” -> add a “the” before JS: “with the JavaScript built-in…”
page 22: “Identifiers, or ids for short, are…” <- Add those commas for apposition.
page 22: You want to refer to the “!” operator. Would it be possible to render it in a codeblock so that it’s clear it’s not an exclamation point?
page 23: “reverse of it” -> should be “its inverse” or “its opposite”
page 24: “Not all combinations of ASTs make sense” <- change “makes” to “make”
page 25: It may be a good idea to show an example of every in the TypeScript Basics chapter; I get what it’s doing but it may not be clear if you aren’t a JS or TS user.
page 28: “Becomes,” should be “becomes” or “becomes:”
page 29: “distingtion” should be “distinction”
page 29: “assinging” should be “assigning”. Sentence maybe should be “JavaScript allows assignment of a variable that is not defined;”. Add a semicolon to the end of the clause instead of a colon
page 30: “Let’s look at how a larger snippet looks like when converted to an AST” change to “Let’s look at a larger snippet when converted to an AST”; omit the “looks like”
2 Likes
I’m really enjoying the draft so far. I’m not having trouble understanding what you’ve written even though I don’t know TypeScript (but I do use OCaml and Haskell so I’m fine with the functional paradigm and recursive data types).
I applaud your choice of ARM 
1 Like
I don’t see a date in my old download link. I only see “2 downloads remaining”.