Thanks. It looks like I forgot to remove those tests when removing features from the Python port of the "Simple Interactive Interpreter" kata, and then those tests got carried over to the Ruby and Java versions as well. I've removed the tests from all three versions. They were already not present in the JS version.

I will also go ahead and disable eval in Python.

That's intentional. The "Simple" version is designed to be a superset of the "Simpler" version.

Hey, sorry for the late reply.

1. Not sure I agree with this one. fn should be an unambiguous identifier, and is not specifically reserved by the spec.
2. My solution already coverd this, but I have added a test to enforce it.
3. Should already be covered by existing tests, since fn is not defined in the arguments list.
4. Should be OK per the same rational as 1
5. My solution did not cover this case. I have fixed my solution and added a test case to cover it.

Thanks for the feedback! If you would like to make a detailed case for 1 and/or 4, I'll gladly consider it.

The arity of the function does need to be taken into account. Since only functions which have already been declared may be called, the intepreter has all of the information it needs to make that call.

As a more general example, take the following expression in Polish (prefix) notation:

* + 1 2 2

A prefix interpreter knows that + is a binary operator, so it takes the 1 2 as the arguments to +, then * takes the resulting 3 2, resulting in 6.

Likewise, in your example the interpreter knows that echo is a unary function, so it takes only the first argument in the stack.

Hope that helps. If there was any particular part of the description that led you to believe that arity wouldn't need to be taken into account, please let me know and I will try to clarify that section.

I've added a test for "9", and it works correctly for my solutions in both JavaScript and Python. Note that numbers are defined as as a sequence of digits (with an optional decimal part), and no unary minus operator is defined. Your second two expressions are therefore not valid inputs.

Yes, it is disabled. I'm not sure why it would be enabled when you're running your own tests. Sounds like a site bug to me.

Fixed. It would be really nice if example test cases were run against the reference solution during validation...

Interesting. Apparently the JavaScript and Python test frameworks are a bit inconsistent. Fixed now.

Fixed by disallowing the require function.

Note the word "interpreter" in the kata title. There is no "compile time"; each statement is evaluated as it is entered. As such, the correct interpretation of the input a b c is dependent on the context of the preceding statments.

Is is allways possible to create variables by assigning to them (e.g. 1+(x=2) with x undeclared)?

Yes. There is no seperate variable decleration syntax; variables are always created when they are first assigned.

May functions access global variables (according to the test cases, the global variable z should be rejected as unknown)?

No. Functions here are akin to mathematical functions. That is, a function operates solely on the specified inputs and produces exactly one output. This behavior is covered both by the kata description and the test cases.

May they access other functions? Should there be a test for loop-calls (since it is not possible to terminate recursion)?

I'm inclined to leave this as undefined behavior. My original solution does not support calling functions inside of another function's body, but I don't see the point in explicitly disallowing it either.

The test cases can be passed by short-cutting many features of the language. Functions calling other functions don't need to be supported to pass the tests as well as functions without arguments. The simplest solution just would switch-case the finite number of test cases and return the appropriate result. My solution rejects ' ' as input, which seems unintended.

Functions calling other functions isn't part of the spec as discussed above. Not testing parameterless functions was an oversight, and I've added a couple tests to cover them.

If someone really wants to write a switch to cover every test case, they're more than welcome to do so. I'm not really interested in thwarting anyone that determined to ignore the spirit of the kata.

There should be at least one randomized test, preferably with functions having an unpredictable number of arguments and in unpredictable composition. Eventually, the interpreter should reject an input like '1 2', which is currently not tested. e.g. in my solution, parsing is done as far as possible and then the result is returned to the caller. The outer function must check that the whole input is read. If I left this check out, the result of evaluating '1 2' would be '1', but throwing an error makes more sense to me.

I dislike the unpredictableness of randomized tests. A random test is just as likely to allow a submission to pass as it is to generate a valid corner case. I would prefer to identify specific corner cases and add non-random tests for them. I agree that throwing an error is the correct behavior for the input '1 2', and I have added a test to that effect. I'm happy to add tests for other specific issues that you can come up with as well.

Thanks for your feedback. I found and removed two references to functions in the description.

You should be able to click "View Solution" right below my comment.

Thanks! I'm very pleased that you enjoyed it.

I've fixed the grammatical errors and added two additional tests that combine method chaining and invalid arg counts.

Thanks. Disabled Function as well now. ;)