Show HN: ShivyC – Hobby C compiler created in Python • Hacker News Board

Re: Show HN: ShivyC – Hobby C compiler created in Python

#11

Post by dangerbird2 » Sat, Mar 31, 2018, 3:51 PM UTC

JasonFruit wrote: post #5

userbinator wrote: post #3

The parser has a somewhat unusual structure: https://github.com/ShivamSarodia/ShivyC/blob/master/shivyc/p... It's been a while since I've had to use the phrase "exception-oriented programming", but it fits that code well. While that might be a useful or even necessary pattern to parse something like C++ which can have almost unbounded ambiguities, AFAIK C can be parsed solely by branching on the next token in the str…

That's not an uncommon practice in Python based on its (relatively) fast handling of exceptions. Maybe you could call it "break things and move fast."

Python implements iterators by raising a GeneratorExit, StopIteration or StopAsyncIteration exception. Exception handling is one of the core means of control flow in python along with function calls and if statements.

Also, because python lacks gotos and switch statements, "exception-oriented" code is a good way to implement efficient finite state machines common in compiler code.

Re: Show HN: ShivyC – Hobby C compiler created in Python

#12

Post by [deleted] » Sat, Mar 31, 2018, 4:11 PM UTC

userbinator wrote: post #3

The parser has a somewhat unusual structure: https://github.com/ShivamSarodia/ShivyC/blob/master/shivyc/p... It's been a while since I've had to use the phrase "exception-oriented programming", but it fits that code well. While that might be a useful or even necessary pattern to parse something like C++ which can have almost unbounded ambiguities, AFAIK C can be parsed solely by branching on the next token in the str…

[deleted]

Re: Show HN: ShivyC – Hobby C compiler created in Python

#13

Post by ssarodia » Sat, Mar 31, 2018, 4:29 PM UTC

userbinator wrote: post #3

The parser has a somewhat unusual structure: https://github.com/ShivamSarodia/ShivyC/blob/master/shivyc/p... It's been a while since I've had to use the phrase "exception-oriented programming", but it fits that code well. While that might be a useful or even necessary pattern to parse something like C++ which can have almost unbounded ambiguities, AFAIK C can be parsed solely by branching on the next token in the str…

Thanks for your feedback! :)

The main downside I see to branching on the next token within the parse_statement function itself is that doing so would split logic between the parse_* functions called by parse_statement (parse_if_statement, parse_while_statement, etc) and the parse_statement function itself.

For example, suppose parse_statement was modified to only calling `parse_if_statement` if the next token was an `if`, thus avoiding the try-except pattern. Then, while parse_statement would be responsible for checking if the next token is `if`, parse_if_statement would be responsible for parsing the `(` token, the expression that follows, the closing `)`, and so on. I figured it was easier to keep the entire identity of an if-statement within the parse_if_statement function itself rather than splitting it between the parse_statement and parse_if_statement functions.