I just played around with it quickly, pasted in the recursive definition of factorial:
(def fact (x) (if (< x 1) 1 (* x (fact (- x 1)))))
It was fairly quick, but the results came back as floating point numbers. It broke on (fact 100).
Under arc-over-scheme it did better.
CLISP performed better than both, but the default limit in the call depth was easily exceeded (E.g. it busted on (fact 8000)). I don't recall exactly, but for around fact 5000 CLISP seemed about twice as fast as arc-over-scheme.
These are very rough estimates, but perhaps give people an intuition about performance.
Now what I am really waiting for is the arc-over-CLISP. I am too busy with other things to dare an attempt...
I tried factorial as one of my test cases. Up through factorial 10 it was still coming back as integers. You may have triggered some overflow condition. The interpreter uses the native JavaScript + operation, then checks whether result == Math.round(result) to see whether it should wrap it in an int or a num.
I'm truly amazed you got it to work up to (fact 100), and that it came back in a reasonable amount of time. Firefox has a recursion limit depth of 1000, which means that the interpreter overhead is only about a factor of 10. I was expecting much more...
I just played around with it quickly, pasted in the recursive definition of factorial:
(def fact (x) (if (< x 1) 1 (* x (fact (- x 1)))))
It was fairly quick, but the results came back as floating point numbers. It broke on (fact 100).
Under arc-over-scheme it did better.
CLISP performed better than both, but the default limit in the call depth was easily exceeded (E.g. it busted on (fact 8000)). I don't recall exactly, but for around fact 5000 CLISP seemed about twice as fast as arc-over-scheme.
These are very rough estimates, but perhaps give people an intuition about performance.
Now what I am really waiting for is the arc-over-CLISP. I am too busy with other things to dare an attempt...