Closed offlinemark closed 8 years ago
@mossberg nice cleanup. I'm not sure why I made a hash table for this, this is clearly better.
@mossberg I can add a few tests to this branch if it would help make clear the interface and expectations of the parse function. There are a few cases to consider with the matching brackets.
@nixpulvis i could give a shot at that
the parse cases I can think of:
if I add an Error:InvalidProgram, seems like parse should return a Result<Program, InvalidProgram>
?
Yea exactly.
Actually Result<Program, Error>
but the right idea, since Error::InvalidProgram
itself isn't s type.
actually this will break in regards to comment blocks. it will count comment brackets as actual code
There is no such thing as a comment bracket, they are just brackets that will always skip over. See #20 for more about skipping irrelevant code.
right, but as of now, the "syntax analysis" in parse
treats everything as code, even if it doesn't matter during runtime.
i guess that's an implementation decision. does incidental brainfuck code in a "comment" block need to be syntactically accurate? i feel like the "spirit" of brainfuck would say that the interpreter should not care.
example
[this is my comment block. this single bracket -> ] will cause an imbalance in brackets and cause an invalid program error, even though during execution, it's fine
]
+++[-,.]
I see what you are saying now. Well, I'd guess most brainfuck interpreters don't preproces. You could try to find one that died and see what it does. For now until we have work done for #20 I'd say it's fine to require matching brackets in comments.
@nixpulvis if there are no other comments, i'll go ahead and merge on your ok
LGTM
Figured there might be feedback, best to submit for review