Yes, the input validation was removed.
The tests now only pass valid inputs.

"The example tests introduce a requirement to silently ignore invalid input, which is wrong in several ways."

• What can I do about this? Should I throw an Error?

Either remove the requirement and only pass valid arguments, or have solvers throw an Error when encountering this.

signature of function arguments passed to the createPipeline is

Passig invalid arguments breaks this promise. In general, input validation doesn't add to kata. In real life situations, validating inputs may be useful, but for kata, simplify the task ( input validation never is the primary task anyway ), and promise us valid input. Preferably explicitly, so we know we can focus on the essential task.

Accepting multiple encodings of arguments essentially has the same problem: it doesn't add to the kata, and just distracts from the essential task.

Was the input validation removed? Might be nice to mention that. I fully agree with removing it BTW, but I am confused now.

Needs more random tests. Some tests with randomly chosen input functions as well, at least ( you can just do some random calculations that always succeed in those functions ).

I think it's a lot better! It can be better still, I think, but I have hopes for this one.

Suic, what is your opinion? Does this have a place on CW and is it down to the details now? Or is it really not different enough?

pipeline is passed binary functions, but returns a unary one. Make that explicit?

Also, the last input function should have the identity function as its next. Also make that explicit? That also explains why pipeline() should return id. People who don't know Monoids, not knowing any better, might pass null instead of id.

  typeof(createPipeline());//Function
  createPipeline()(true);// true
  createPipeline()(false);// false

This really should be part the spec: pipeline() should return the identity function. It should therefore be in the description proper, not hidden away in the examples.

Adding some more structure to the description may help us, and yourself as well, fully comprehend it. You might have sections Task, Examples and Inspiration, with Task containing all of the specs and none of the examples. Keep different things separated.

I would suggest to have pipeline accept either (...fns) or an Array of Functions, not both. Why complicate things?

Callers can easily add or remove a pair of square brackets, you're not really making things easier on them, and it's not essential to the function composition.

I'd suggest passing an Array; it's the cleanest way to pass in a single, consistently typed object that may contain zero or more consistently typed objects ( i.e. functions ). ( It also makes some translations easier. )

It has been in Draft in the interim. So he must have republished it.

There have been changes ( it has a different name at least ); I'll see if I want to update my rating.

I refactored the description.

I unpublished the kata, I think I'm not prepared yet to publish it.

The kata is still published.

try to replace function snailArr by closure $snailArr = function(){} or declare the function function
outside of the of the snail function. :)

Java programmer detected.

Duplicate.

Simple Pig Latin

I guess you should improve the tests and description.

1. The description should be most specific which the 'a' is before 'm' in any position of array.

The test should cover:

• The case of 'a' is present but 'm' is not present in array.
  Ex: ['b','x','a','j']
• The case of multiples 'm' one before and one after.
  Ex: ['m','i','a','j','m']