Timeline for Haskell Brainf*ck interpreter: runtime error handling
Current License: CC BY-SA 3.0
13 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 31, 2017 at 19:57 | comment | added | Vogel612 | and that is why "matched parens" is not a type-3 language, but a type-2 language | |
Aug 30, 2017 at 11:25 | vote | accept | penkovsky | ||
Aug 30, 2017 at 11:14 | comment | added | penkovsky | I like how elegant becomes the program type/structure now. I really enjoyed thinking in terms of functions forward, backward, modify, and value on a new Tape structure. However, now writing a parser without external libraries becomes very tricky. The handleLoop function has not only to look for the ']' character but also beware of nested loops and the current indentation level. That exercise is actually harder than designing an interpreter itself! | |
Aug 30, 2017 at 9:14 | comment | added | penkovsky | Let us continue this discussion in chat. | |
Aug 30, 2017 at 8:38 | comment | added | Zeta | Depends on your parsing library, if you want to use one. If you don't want to use one, you have to come up with a way to store those in your current parsing state. | |
Aug 30, 2017 at 8:08 | comment | added | penkovsky | By the way, what is the idiomatic way to provide the line and column numbers when failing to parse the instructions code? | |
Aug 30, 2017 at 8:00 | comment | added | penkovsky | Depends on what 'non-trivial' means. I would try to track (recurrent) patterns in the tape state change. | |
Aug 30, 2017 at 7:56 | comment | added | Zeta |
I'd use either EItherT from either or ExceptT and therefore prefer your latter suggestion. bracket is great for IO but you can handle almost everything in pure code. By the way, how would you detect (non-trivial) infinite loops?
|
|
Aug 30, 2017 at 7:49 | comment | added | penkovsky | Zeta, thank you for the nice answer. One can imagine different runtime exceptions: accessing an invalid memory cell (on the left), infinite loops, encountering an invalid (>255) character input, or no input line at all, etc. Shall one prefer brackets from Control.Exception or runExceptT from Control.Monad.Except? How about error recovering (e.g. asking a valid symbol) instead of crashing? | |
Aug 30, 2017 at 6:53 | history | edited | Zeta | CC BY-SA 3.0 |
fix formatting
|
Aug 30, 2017 at 6:27 | history | edited | Zeta | CC BY-SA 3.0 |
fix formatting
|
Aug 29, 2017 at 20:54 | comment | added | Zeta |
I have to revisit this review tomorrow, but I really need to get some sleep now. What's missing is that your code uses an "instruction pointer" (your position i ), which isn't really necessary if you use recursion properly. For some more inspiration, see my older reviews on codereview.stackexchange.com/q/128833/21002 or codereview.stackexchange.com/q/165318/21002.
|
|
Aug 29, 2017 at 20:48 | history | answered | Zeta | CC BY-SA 3.0 |