Thanks. Random tests are now added.

Needs Random Tests.

Thanks for that push-back, I'll keep that in mind in the future.

Sure. From my point of view, I have quite a few translations to review, and that task becomes difficult when they deviate from the original. Anyway - thanks for this. Now it is approved.

I have an idea for a kata, basically reducable to "produce the shortest sequence of numbers you can that iterates over every possible 4-digit number at least once during the sequence, i.e., 12345 hits 1234 and 2345." I could just write a test and maybe figure out mathematically the shortest possible sequence, but honestly I think having people compete not just on the usual "does it pass tests" and "does it follow best practices" and "is it clever" but "who got the shortest result versus longest result" just to make it a little more fun. It doesn't seem like it's possible to "score" solutions in this way, though.

That then got me thinking about other ways to score kata, like benchmarking, shortest sequence of instructions (or AST), etc., but for now I'll settle with shortest output. Any ideas?

I called the "fallShort" case "should stop when no more dice", trying to follow the description conventions of the test framework the site uses.

Missing the "fallShort" test case?

In the Go translation, it is idiomatic Go to accept a nil slice as an empty slice, but the tests require an allocated empty slice. This test should probably be relaxed so that results like this are acceptable:

func foo(...) (result []interface{}) {
  for some_condition {
    ...
    result = append(result, item)
  }
  return
}

Just came to add that requiring the returned slice be an actual allocated []string{} isn't very idiomatic. In Go, a nil slice is an acceptable form of an empty slice.

var x []string
for need_to_do_something() {
  x = append(x, some_value())
}
return x

The above is idiomatic Go and the current translation disallows it.

The description states:

References to variables not found in the argument list should result in an error when the function is defined.

So fn add x y => x z is an error, even if z is defined in the global scope.

I hit this too. I generally find "import foo" a better practice since it makes it clearer to your readers when you're using something from another module.

I can't get this test to pass for Python 3:

input: 'fn add x y => x + z'

This should raise an error, and when I test this by hand with this exact input, my code correctly raises the error about z not being recognized. All of my other tests pass. Advice? Is there a problem or quirk with this test?

The random tests appear to assume that the list will not be modified in place. If it is a requirement that the list not be modified in place, the instructions should reflect that, or the random tests should be made robust against it so that it's a legal solution.