Either remove reduce from Array.prototype, or check whether foldl is actually used in sum, join, …. Also, the recursive variants aren't mentioned in the description. You should also check whether they're actually recursive.

Description definitely needs more, uhm, description.

• You should move explanation from comments in code to description. Especially examples.

• You should explain better meaning of init parameter and behaviour in some edge cases like single-value or empty array.

• What is the difference between sum and sumRec? Is 'Resursive' meant to be 'Recursive'? What does it have to do with foldl? Anyway even if there should be difference tests don't seem to test it - i simply copied body of sum to sumRec and it passed all tests.

• Last test is confusing, if it fails it says that it test join of [3,5] and somehow expect ''. Actually it tests empty array so expected result is correct, but I had to console.log arguments to find it.

And a little suggestion - if you say that foldl is quit__e__(please fix this misspell too) similar to Array.prototype.reduce, maybe you should define it same way - Array.prototype.foldl?

Description is too short.
Please provide test cases.

You have to correct the order of actual and expected in your test cases.

You could maybe prevent reduce method usage.

There are several issues here, two of which have already been mentioned. The test cases have "expected" and "actual" reversed, which is confusing, and the built in reduce method needs to be disabled. The honor system isn't really the right way to handle this.

Another issue is that you don't even know that foldl has been implemented correctly. That's easy enough to test directly.

I see two more severe issues that probably can't be fixed perfectly, but can be mitigated:

1. There's no test to make sure that you're actually using foldl to implement these functions. You could just as easily do a for loop, and the tests would pass.

2. There's no test to make sure the recursive implementations are actually recursive. You can just as easily implement them by passing to the foldl based implementations, and the tests will pass.

Now, to mitigate number 1, I would recommend that you do a test like this:

var tmp = foldl;
var x = Math.random();
foldl = function(fn, init, xs) { return x; }
Test.expect(sum([1]) === x, "sum must be implemented using foldl"
foldl = tmp

If the warrior cheats and doesn't use foldl, the test will fail.

For number 2, you can do:

var tmp = sumRec;
var recursive = false;
sumRec = function(){ recursive = true; return 1; }
tmp([1]);
Test.expect(recursive, "sumRec must be recursive");
sumRec = tmp;

This ensures that sumRec at least calls itself.

In both cases, you'll of course want similar tests for prod and join.

Really thanks your suggestion.
I did think about disable built-in method. However I believe people are bacially good so I did not do it yet.

Thanks - helped me further :)

Still struggling expectations to join...

And now - finally got it.

Some work on the test cases is still pending, to be honest. Output for last test case is misleading.

It looks like the arguments to Test.assertEquals are reversed in the test cases, so what it's reporting as expected value is really the actual value, and vice versa. It's also confusing because the tests compare the result from sum and the correct value, and then the result from sum with the result from sumRec, instead of checking sumRec directly against the correct value.

Well, I get:

sum [] is 0:

Test Passed: Value == 0

Test Failed: Expected: NaN, instead got: 0

The test clearly state "sum [] is 0" - then "Expected NaN"?!
I don't get it :)

None of the functions are stated to return NaN in any case. Nor is this given in the description. And - even explicitly returning NaN if input is an empty array/list - the result is not the expected NaN... If you want to check against NaN you must use isNaN() - NaN===NaN is false!

Also, what is the expected output of prod/prodRec given an empty array/list? 0, 1, NaN, Inifinity, ...?

Hi ssineriz,

Thanks your feedback.

1. Corrected.
2. The recursive one is not desired to use foldl but the non-recursive one. I actually mentioned in comments in solution setup.
3. It is design to be exact same with native join but just practice some FP things.

Yes, it is a Haskell practice and I convert to JavaScript. ;)

Hi freizl, I'm sorry to signal you some little issues:

1. I've got a prod and prodRec as undefined reference error (had to define these two variables myself)
2. The request of a recursive implementation of sum and prod isn't too much clear: I guess the exercise is to use also foldl for the recursive form.
3. Your solution for the 'join' method is different from the native join: with an array of n empty strings, you would return an empty string whereas native join would return a string made of n-1 delimiters.

Once corrected, this kata makes a pretty bridge to Haskell :) (I suggest to mention that too!)