Oh, please!! 🤦😭

This solution is obsolete, please see my better one here:

https://www.codewars.com/kata/reviews/634836df8cdfd90001d42728/groups/6556bb195702a80001bc9ef8

Yes, although I don't think I would call these "abstractions". :)

oh thanks for the feedback! you mean to use the code directly in place instead of creating the abstractions? if i understood correctly it's a good point. ty again

"value-or-minus1" and "str-n" are unnecessary.

See my solution and comment here:

https://www.codewars.com/kata/reviews/60355d9211d5420001b6043c/groups/6550256299b1c40001f15e56

This tail-recursive solution is provided for illustrative purposes.
Note that Tail Call Optimization (TCO) is Common Lisp implementation specific.

Since the recursive call to itself is the last thing done by function RECURSE,
there is no actual need to ever return to the stack frame, so it can be deallocated before recursing, or it could simply be reused.

Effectively, this is an iterative solution expressed in a recursive way.

It seems SBCL does not perform TCO by default since it can make debugging harder,
hence the need for (declare (optimize (debug 0))).

Try (summation 100000000) in your favorite Common Lisp implementation and see if it blows up the stack!

I understand. In that scenario, I would assume that there is a method or keyword to implement safe stack recursion.

I suspected there was a direct mathematical solution, but was not able to figure it out on my own, and I did not want to try finding the solution on the internet, as on CodeWars I want to use my own original solutions only, so I went for the obvious one.

I saw the direct mathematical solution after submitting my answer, but did not want to resubmit just to copy the better solution, as again on CodeWars I want to use my own original solutions only. I don't want to get into bad habits.

I hope this is to your satisfaction.

Dividing by 2 would be clearer than multiplying by 0.5...

Both solutions are O(n), what makes them equally bad! Check my better, O(1) solution here! ;)

See my better solution here:

https://www.codewars.com/kata/reviews/60355d9211d5420001b6043c/groups/654e63ec18d6a70001b98dac

Note that this solution can easily blow up the stack due to excessive recursion if n is large enough.