.

Haskell translation

this translation modifies the description

I don't know Ruby and its method-chaining, so I don't even understand which way you're arguing here. In Haskell ( which I do know ) with its immutable values, the whole problem never even arises.

Authors don't necessarily know how to design a kata, let alone design it for multiple languages. Can't always blame them for that.

It would certainly be nice if OP made a decision on that two months old suggestion.

I admit that I think the author's intention is that this is a mutable instance with ruby-like chaining of methods. That is how it reads, even if it reads to allow both. but it annoys me. it is to choose a toy interpretation when a correct one exists and is a perfect fit. It annoys me that the kata says to not mutate input, but that it still uses the return value as input for further operations, and THAT input is allowed to be mutated.

I said the same thing here, but I did as I did, not as I said.

ETA: The JS reference solution has the same lack of reusability. But that's never tested for it. :S

See this Suggestion. It's still open, but I implemented it in the JS tests.

Yes, I think Python should have that as well, and the description should probably mention it. I didn't think about that when translating. Mea culpa.

@JohanWiltink IMO your test code needs to say what it is doing and provide reproduction steps. One may argue all bets are off for this kind of mutation and if it was in the solver's own environment then I would agree but here there will always be mistrust in the test code and uncertainty over what's expected. They can't see what the problem is, they have to start guessing, re-read description and hope to find something without knowing if there's even anything there, there's not enough traction for them to go on. Give them a concrete problem they can see.

Python and JS versions aren't equivalent, my python solution doesn't pass in javascript.

Frankly, my python solution shouldn't pass, it's intentionally wrong, and idk why that wasn't fixed before approving the kata out of beta.

Specifically, python lacks this sort of test, where reuse happens after calling move:

a = move(mat)
b = a('up')
c = a('left')
print(b('stop'), c('stop'))  # wrong results for both

The description is a bit ambiguous on this as well, the third note:

The returned function should support being called repeatedly any number of times before "stop" is issued.

does not make it entirely clear whether it is allowed to return the same function instance multiple times. Python allows it, JS does not. It's talking about being capable of being reused, it really SHOULD mean it for every single intermediary function. If it doesn't, then it should clearly say in the description that the return value of move represents a single instance that may be mutated. If that's the case then the JS version isn't compliant. I think that's the wrong way to go, and that the JS version has the superior interpretation.

A kata involving state will either have simple incorrect tests or it will have quite overengineered test code required to actually test state. It's a big reason why OOP is a disaster for kata.

My output [[0,0],[1,0]] not [[1,0],[0,0]]

Incorrect. Your output is [[1,0],[0,0]]. I checked.

I dont modify the inputs or interact with them

Correct. But you are still modifying state outside of a closure. You're not modifying the input to move, but you are modifying state kept outside of inner ( but inside of move ).

I dont modify the inputs or interact with them; instead, I return an array that is independent of the inputs, leaving the inputs unchanged I only read data from them initially

My output [[0,0],[1,0]]
not [[1,0],[0,0]]

Owwwww .. you're modifying your input aren't you?

Don't do that.

The test is

  it("reusable tests", function() {
    let m = move([[0,0],[0,1]]);
    assert.deepEqual( m("stop"), [[0,0],[0,1]], `move([[0,0],[0,1]])("stop")` );
    assert.deepEqual( m("up")("stop"), [[0,1],[0,0]], `move([[0,0],[0,1]])("up")("stop")` );
    assert.deepEqual( m("left")("stop"), [[0,0],[1,0]], `move([[0,0],[0,1]])("left")("stop")` );

Your solution is letting the ("up") affect the ("left").

The syntax is $STATEMENT: expected $YOUR_ANSWER to deeply equal $CORRECT_ANSWER.

Yes, you should have returned [[0,0][1,0]], but you returned [ [ 1, +0 ], [ +0, +0 ] ] instead.

I honestly don't know how you did that, because the 1 moved two positions, and there was only one directional command ( "left" ).

that is what it says that you should have returned, yes. and it says you returned something other than that. there is no why-not. because yes, that.

move([[0,0],[0,1]])("left")("stop"): expected [ [ 1, +0 ], [ +0, +0 ] ] to deeply equal [ [ +0, +0 ], [ 1, +0 ] ]

why not [[0,0][1,0]]