Yeah, looking at the tests, the whole wrapping input and output in a function is unnecessary. Part of the kata is evaluating the expression, but there's some parsing two types of function syntax and wrapping the return value in a function to contend with, both of which are tasks that have nothing to do with arithmetic expression parsing and add relatively little - except for the fact we don't know it's limited to that, so we had better reinvent eval and just let that do the work.

The description doesn't specify what the limits of the expression are, and there's a puzzle tag. So parsing the input is severely discouraged ^*, because it might turn out to be impossible (we don't know what we're going to encounter ), and it becomes a circumventing the artificial, arbitrary, restrictions kata.

If this is to be a parsing kata, specify the expression ( and give me Function, because my own personal parser library needs it ). ( It'll also be a duplicate. )

If you want to disable eval: in JS, you can't; you'll have to create the kata in another language ( e.g. Haskell doesn't have eval ).

^* restricting Function and RegExp doesn't help.

I can, but you won't like it.

The title is "parser," but there's no parsing in sight. Instead, there's circumventing artificial restrictions, which is something I don't like as a kata.

Also, the circumventing is not hardly a 3kyu problem, because (1) enforcing restrictions is hard to do and (2) restricting valid JS is limited to what won't kill the test suite itself, not to mention that (3) it has a tendency to restrict more and more valid JS until the reference solution is the only allowed one.

If your kata has to restrict valid JS to be interesting, I don't think it's a valid kata. Other opinions may be available.

done

Kata is now retired.