I'm glad to see the first solve appears. Happy coding ^_^

No news on this side, so closing.

Hi,

Considering the shape you were talking about, your function should return these three:

+----+
|+--+|
||  ||
||  ||
|+--+|
+----+

+--+
|++|
|++|
+--+

++
++

It matches the description: If you encounter imbricated pieces, both outer and inner shapes have to be returned. so I'm not sure I'll add anything to it unless you can precise what is lacking or why (I need enlightenment here). What were the other possibilities you thought where matching, exactly?

It seems you began the hard way, yeah. I created it that way and went almost crazy with the + => -| thing too... ;) I believed I had found a 1 dan kata, actually. Until lechevalier came by and show me the right way to solve it (you can take a look at my python solution if you want to see the evil way).

More sample tests: that's doable. I'll think about some of them (but not from the random ones).

cheers

The problem with trying to allow functions calling other functions is, we've already decided that functions can't access global variables, and for any given name there can be either a variable or a function, not both (to avoid conflicts).

If I try to define this, it's supposed to give an error, because the variable y is not in the argument list:

fn sum x => x + y

But if sum can call other functions, y doesn't have to be a variable. It could be another function which doesn't require any arguments. And maybe y isn't defined yet. How is it supposed to know when you define sum whether it's valid or not?

Maybe you've defined a global function named y a while ago, but you still meant to define your sum function as this:

fn sum x y => x + y

Since you forgot to put y in the argument list, is it going to use the global y function instead of giving you an error?

Added links to binomial theorem and pascal's triangle.
Added links to relevant kata.

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.