Live data from Hacker News

Working through 'Writing A C Compiler'

jollygoodsw.wordpress.com

31–40 of 44 posts

Re: Working through 'Writing A C Compiler'

#31

Earlier quoted context omitted.

> you are just consuming tokens from a stream. My guy... Do you think that parsers just like... concat tokens into tuples or something....??? Do you not understand that after lexing you have tokens (which are a "type") and AST node construction (an "operation") and that the grammar of a language is naturally a graph .... Like where else would you get the "recursion" from.... If that doesn't make sense I invite you to…

OK I might be wrong about the visitor pattern, but what I really did not like is to use the accept() and visitBlah() way to execute AST nodes: https://craftinginterpreters.com/representing-code.html#the-... I did continue reading the book (not the original author of that reply) but I do think it is distracting for newbies. I had to come back to this page over and over again to recollect memory about the pattern, beca…

Nope, you had it right.

Visitor thoroughly confuses me in the context of parsing (maybe in all contexts.)

visit and accept are not the verbs I want to be seeing in the code. I want to see then, or, and try.

Re: Working through 'Writing A C Compiler'

#32

Earlier quoted context omitted.

> just inspect which tokens are seen and directly construct AST nodes I'll repeat myself: this is not possible because you need to recursively construct the nodes (how else would you get a tree...).

I think I'm missing something here. if you have a grammar rule R with children A and B, and a function in your recursive descent parser that corresponds to R, why can R not call the parser functions for A and B, which return AST nodes themselves, and then construct another AST node using the result of those? Where was the visitor pattern required here?

Me too. No-one's denying that recursion is happening. We're just not sure about it being synonymous with the Visitor Pattern.

Re: Working through 'Writing A C Compiler'

#33
post #31

Earlier quoted context omitted.

OK I might be wrong about the visitor pattern, but what I really did not like is to use the accept() and visitBlah() way to execute AST nodes: https://craftinginterpreters.com/representing-code.html#the-... I did continue reading the book (not the original author of that reply) but I do think it is distracting for newbies. I had to come back to this page over and over again to recollect memory about the pattern, beca…

Nope, you had it right. Visitor thoroughly confuses me in the context of parsing (maybe in all contexts.) visit and accept are not the verbs I want to be seeing in the code. I want to see then , or , and try .

Parsers "accept" or "reject" programs. It's completely standard language.

Re: Working through 'Writing A C Compiler'

#34
post #16

I love this book! I worked through a bunch of it during my winter break last year and found the incremental teaching style extremely rewarding. For readers of the book, Sandler’s reference OCaml implementation is super useful for getting your bearings. I was kind of thrown off by the use of TACKY as an IR, but it was nice to have a solid reference as I worked through the book. For those more experienced with compiler…

> Sandler’s reference OCaml implementation is super useful for getting your bearings

The author also maintains a list of implementations created from the book: https://github.com/nlsandler/c-compiler-implementations

Re: Working through 'Writing A C Compiler'

#35
post #3

The crafting interpreting asks the reader to use the visitor pattern, and this was quite a turn off for me, I stopped there.

I recall back in the day when I was an embedded systems programmer at the coal face I had similar antipathy towards a pattern. I think it was called the State pattern or similar. It involved a class hierarchy and virtual functions, one for basically every state, event pair.

I preferred my simple C design whic used a lookup table to quickly access a structure for each state, event pair instead. The structure would provide an output state, a message to send, an action to emit, a bitmask to select zero or more other standard operations, and yes a function to run in those rare cases where something really special was needed. All fields optional.

The point is I didn't need to write N x M functions, I just needed to edit a table. And I didn't need to understand any rocket science.

Re: Working through 'Writing A C Compiler'

#36
post #31

Earlier quoted context omitted.

Nope, you had it right. Visitor thoroughly confuses me in the context of parsing (maybe in all contexts.) visit and accept are not the verbs I want to be seeing in the code. I want to see then , or , and try .

Parsers "accept" or "reject" programs. It's completely standard language.

Alright, so where can I read more about the visitor pattern's "reject" method?

Re: Working through 'Writing A C Compiler'

#37

Earlier quoted context omitted.

> you are just consuming tokens from a stream. My guy... Do you think that parsers just like... concat tokens into tuples or something....??? Do you not understand that after lexing you have tokens (which are a "type") and AST node construction (an "operation") and that the grammar of a language is naturally a graph .... Like where else would you get the "recursion" from.... If that doesn't make sense I invite you to…

OK I might be wrong about the visitor pattern, but what I really did not like is to use the accept() and visitBlah() way to execute AST nodes: https://craftinginterpreters.com/representing-code.html#the-... I did continue reading the book (not the original author of that reply) but I do think it is distracting for newbies. I had to come back to this page over and over again to recollect memory about the pattern, beca…

> so every time I had to remind myself how this visitBlah() and accept() pair works. I really think a big switch()…

This is just and alternative implementation of the visitor pattern. Whether you implement it using dynamic dispatch or a switch or an if stack its all the same pattern…

Re: Working through 'Writing A C Compiler'

#38
post #16

I love this book! I worked through a bunch of it during my winter break last year and found the incremental teaching style extremely rewarding. For readers of the book, Sandler’s reference OCaml implementation is super useful for getting your bearings. I was kind of thrown off by the use of TACKY as an IR, but it was nice to have a solid reference as I worked through the book. For those more experienced with compiler…

the dragonbook is a good start to go deeper inthink (modern editions). its less practical, more theory heavy. does have all the algos and some example materials. if you have a bit of basis it will be useful reference.

Re: Working through 'Writing A C Compiler'

#39
post #16

I love this book! I worked through a bunch of it during my winter break last year and found the incremental teaching style extremely rewarding. For readers of the book, Sandler’s reference OCaml implementation is super useful for getting your bearings. I was kind of thrown off by the use of TACKY as an IR, but it was nice to have a solid reference as I worked through the book. For those more experienced with compiler…

There’s https://www.amazon.com/SSA_based-Compiler-Design/dp/30308051...

Re: Working through 'Writing A C Compiler'

#40
post #36

Earlier quoted context omitted.

Parsers "accept" or "reject" programs. It's completely standard language.

Alright, so where can I read more about the visitor pattern's "reject" method?

> all other tokens should flag an error

Ie the link I posted above

Post reply on HN