HNHacker News
TopNewBestAskShowJobs

ssarodia

59 karma · joined May 5, 2016

submissionscomments
ssarodia··on Show HN: Lotus – Open source pricing and packaging infrastructure
Love to see Lotus out there and excited to see where this goes next!
ssarodia··on Medium tries to prevent people reading deleted articles on the Wayback Machine?
Just fyi, on Chrome on Android you can Share -> Print -> Save as PDF.
ssarodia··on Ask HN: Python Open Source Projects for someone learning it after Java/Scala
(self-promotion) I've created an open source C compiler written in Python (https://github.com/ShivamSarodia/ShivyC). I've learned a ton building it out so far, and I've found compiler design to be a great exercise in software engineering and learning Python since managing the complexity of a compiler is nontrivial. If you're interested in contributing, a good place to start is by tackling any of the issues marked as "good first issue".
ssarodia··on Show HN: ShivyC – Hobby C compiler created in Python
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.