foldr

Introducing reduceRight, version -1

JavaScript reduceRight ( reference ) will, given a Function and an initial value, reduce an Array to a single value by iterating it, and the initial value, right to left and folding it with the given Function ( ignoring special cases for simplicity ).

Array.prototype.reduceRight ~= function reduceRight(fn,z) {
  for ( const v of this.reverse() )
    z = fn(z,v);
  return z;
}

Given that Arrays will always be finite and JavaScript evaluation is strict, this is functionally equivalent to

Array.prototype.foldr ~= function foldr(fn,z) {
  if ( this.length===0 )
    return z;
  else
    return fn( this[0], this.slice(1).foldr(fn,z) );
};

Note that

• the arguments of fn have been reversed ( this is simply a matter of convention, and inconsequential )
• this may require a lot of stack ( depending on this )
• fn() is evaluated right to left even though the list is iterated left to right

Introducing laziness

Now imagine that fn arguments are evaluated lazily - evaluated only if and when required. Suddenly, also an infinite list might be folded ( reduced ) to a valid value, if, somewhere before infinity, fn returns a value without evaluating its second argument.
Both reduceRight and foldr encapsulate recursion, but where reduceRight will always process the entire list, foldr with lazy evaluation may arrive at the base case and end the recursion before having processed the entire list.
Infinite lists are beyond the scope of this kata; this kata's scope is ending the recursion when appropriate, possibly before processing the entire list, by being lazy. Think of it as efficient. :]

Task

Define Array method foldr, which takes a function and an initial value as arguments, and returns a lazily evaluated fold over its this-argument.
Also define String method foldr, which simply treats Strings as Arrays of characters ( this often works out of the box in JavaScript ).
There will be tests with Arrays of Numbers, characters ( i.e. Strings ) and Booleans. You can see essentially all testing in the Example Tests; there will be no surprises in the Submit Tests, only more, random, testing.

Validation

Input Arrays are dense.
Test cases are not designed to overflow the stack.
All input is valid.
There is no need to solve the kata for untested cases. If you do anyway, you have earned the right to boast in the comments! :P

Notes

The initial value and the folding function are not independent entities. Often, the initial value is the ( right, where applicable ) identity of the folding function.
The fn ( and foldr ) return value and the initial value generally have the same type. JavaScript does not enforce this, like Haskell, where foldr has equivalent type signature [ a ].foldr( function(a,b) => b , b ) => b ( a,b are type variables ), but this kata will conform to this.
The exception to this is that the initial value may be undefined ( which in Haskell is polymorphic and therefore still has the same type as the fn return value ).
Absent type signatures ( which would provide the fn return type even when the initial value is undefined ), for this kata you may then assume the return type is the list element type ( which, unlike in Haskell, in JavaScript can vary. but it won't ).

Cheating by probing the folding function should be complicated (enough). If cheating involving the counter turns out to be a problem, that, too, can be obfuscated. But I hope I don't have to. Play nice!

Happy coding! ^_^