You might be interested in
https://github.com/amalloy/clusp/blob/master/src/snusp/core.clj, my Clojure
interpreter for SNUSP (which is brainfuck with different control-flow
mechanics). It's purely functional, and IMO does a good job of separating
concerns; both of those are things it sounds lik
Awesome! I've been re-factoring my code but I am having difficulty figuring
out how to deal with state without manipulating global state; my first
thought was to create a binding form within a doseq in a function that
executed each instruction and mutated the cells when necessary--but that
did
And feel free to steal ideas from my Clojure BF->Native compiler.
https://github.com/halgari/mjolnir/blob/master/src/examples/bf.clj
Mjolnir Expressions are a bit different than Clojure, but it shouldn't be
to hard to write a BF Clojure compiler using this as a starting place.
Notice how the entir
Incidentally, this thread made me feel a sudden desire to write my own
bf interpreter. Feel free to take a look at
https://github.com/michalmarczyk/bf.clj
if you'd like. :-)
Cheers,
Michał
On 7 April 2013 05:23, Sean Corfield wrote:
> I agree. I see nothing that sets the code pointer back to
I agree. I see nothing that sets the code pointer back to the start of the loop.
I also agree with Michał's suggestion that getting rid of global state
and making this more functional in style will make it much easier to
read, debug and maintain - as it stands it not very idiomatic for
Clojure.
S
PS. The above would mean that the loop/recur terminates as expected,
it's just that next time this function is called it starts executing
instructions at the wrong spot.
Anyway, I agree that factoring the code in a more manageable fashion
may be a more useful first step than hunting individual bug
Not sure why you're using (- end-index 2) in the printed message.
Also, you can use (dec end-index) in your termination condition.
As for the main problem, I haven't studied your program very closely,
but it seems to me that your program counter may never get reset to
the beginning of the loop, in
If there's too much incidental complexity and you know it, try working on
reducing that first. It's quite likely the bug will shake out while you're
doing so, and if not, it is likely to be much easier to find after you
simplify and refactor the code.
--
--
You received this message because you
