Oh yeah, true.

The case I was surprised there was no test for was 1 + x + 2 should simplify to x + 3, but I definitely had fun regardless

No, it's honestly fine I think. All the test cases are associative towards the right anyway, i.e. a*b*c is treated as a*(b*c). Same for plus.

For point 2, the problem description should be clear which associativity to use, even if both left and right are mathematically correct. If this is not the case, please raise an issue.

after taking a break from codewars for a few months, it feels great to solve a difficult question in only a few hours. So, it's either I've gotten way better or this kata was a little bit easy for 1kyu. It's probably the latter, realistically speaking though- lol.

Anyway, this was a great kata- I've never written a compiler before, and this kata really helped me understand how they work. Some suggestions:

1. The pass2 constraints are very lenient. As mentioned also by someone else in the comments, pass2 should also remove unnecessary +0s, *1s, etc. (i.e. pass2({'op': '+', 'a': {'op': 'arg', 'n': 0}, 'b': 0} should return {'op': 'arg', 'n': 0})

2. Some "different" solutions are the same, algebraically, because operations like adding and multiplying are associative. The test suite should let these solutions pass too. I know, an infinite number of solutions now are possible, but it would be nice to have some leeway.

-goldenratio161

These should all (besides random tests) be fixed now thanks to mjpeters' fork. (?) Please open new issues for any new problems found.

Approved

In the description we have that

All test cases will be valid programs

but then nowhere we have a description that program is just one function.

I think either adding program ::= function to the grammar, or saying that testcases will be valid functions would save me quite some confusion and probably few minutes.

I've re-written the Rust translation, to address a number of issues:

• Initial training setup no longer uses outdated rust syntax, and compiles cleanly.
• Provides a pre-defined Ast enum, including derive(Debug).
• Provide enums for the binop operations (add, sub, mul, div), and for the value sources (imm or arg)
• It still provides a sample tokenizer (like the other translations) but no longer tests it or requires that it is still there in the solution. Trainees should be able to use alternative approaches.
• The sample tokenizer now shares string slices with the underlying program string slice.
• Ensure that the operator associativity test fails if the solution outputs an empty assembly vector.
• Because the provided enums implement Debug, test error output should be much better.
• No longer tests the provided simulator or if the compiler can be created.

Please approve!

I've created a fork that addresses all of these issues except for the randomised tests, since none of the other translations have randomised tests either.

And another issue:

• The sample tests do nothing. They instead comprise the simulator and a small test for the simulator. 🤦‍♂️

Seemed like the fixed tests either got added or removed some time ago, because I saw all languages have unified fixed test cases now, would have to check and verify it again later ^^

Description can & should be made language agnostic.

Sorry, which testcase is it that should be added?

I'm fixing the Ruby version.

Nice kata, good if you want to learn about closures