5 ms·
Show HN: ShivyC – Hobby C compiler created in Python
- deaddodo 8y agoNow, compile CPython in it and you're fully boot strapped.
- rs86 8y agoCool!!!!!! Really cool! Did you try it?
- userbinator 8y agoThe parser has a somewhat unusual structure: https://github.com/ShivamSarodia/ShivyC/blob/master/shivyc/parser/statement.py 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 stream except for one tiny case (typedefs).
- app4soft 8y agoSo, is it issue? If so, please, report it for developer on Github[0] Or you know how to fix it? Then just pull[1] it to 'master' ;-) [0] https://github.com/ShivamSarodia/ShivyC/issues https://github.com/ShivamSarodia/ShivyC/issues [1] https://github.com/ShivamSarodia/ShivyC/pulls https://github.com/ShivamSarodia/ShivyC/pulls
- JasonFruit 8y agoThat'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."
- lou1306 8y agoUsing exceptions is totally common, but this seems to raise/catch/log 6 errors each time it tries to parse a `for` statement. I'm a noob when it comes to compilers, but maybe a token -> function dictionary would be a better approach?
- JasonFruit 8y agoThat does sound a bit extreme. (I freely admit I went by this description and never looked at the parser code myself, though some other portions I did read were pretty normal Python.)
- dangerbird2 8y agoPython 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.
- pebers 8y agoIt looks like that's what it is doing: https://github.com/ShivamSarodia/ShivyC/blob/156a71bce7f340db0fa03eabfbf5ca31122b69d9/shivyc/parser/utils.py#L110 https://github.com/ShivamSarodia/ShivyC/blob/156a71bce7f340d... The exceptions seem to be how it signals failure if the token doesn't match, but they aren't being used for unbounded lookahead.
- skocznymroczny 8y agoEAFP - Easier to ask for forgiveness than permission - is a popular idiom in Pythonic code. Unlike languages like C++ or Java, where you usually check for condition first and then proceed (which can introduce race conditions in multithreaded code if done improperly).
- deleted 8y ago[deleted]
- ssarodia 8y agoThanks 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.