Develop Reference

Using filter() to implemnt curriable() in javascript is fial , however, uisng map() is work, why?

I'm trying to implement the curry() with placeholder support, that is curriable. curriable provides a high performance and small footprint curry method. The version1 is the working code
is using map in the recursion function. However, I tried to use filter to filter the placeholder in the version2! Using filter is good for most cases, but fail with case curriedJoin(_,_,3,4)(1,_)(2,5) withe reason Uncaught TypeError: curriedJoin(...)(...) is not a function, can any one tell me why?
version 1
/**
* #param { (...args: any[]) => any } fn
* #returns { (...args: any[]) => any }
*/
// function curry(fn) {
// // your code here
// }
function curry(func) {
return function curried(...args) {
const complete = args.length >= func.length && !args.slice(0, func.length).includes(curry.placeholder);
if(complete) {
args.length=3
args.sort((a,b)=>a-b)
return func.apply(this, args)
}
return function(...newArgs) {
// replace placeholders in args with values from newArgs using map
const res = args.map(arg => arg === curry.placeholder && newArgs.length ? newArgs.shift() : arg);
return curried(...res, ...newArgs);
}
}
}
const join = (a, b, c) => {
return `${a}_${b}_${c}`
}
curry.placeholder = Symbol()
const curriedJoin = curry(join)
const _ = curry.placeholder
console.log(curriedJoin(1, 2, 3)) // '1_2_3'
console.log(curriedJoin(_, 2)(1, 3)) // '1_2_3'
console.log(curriedJoin(_, _, _)(1)(_, 3)(2)) // '1_2_3'
console.log(curriedJoin(_,_,3,4)(1,_)(2,5))// '1_2_3'
Version2
/**
* #param { (...args: any[]) => any } fn
* #returns { (...args: any[]) => any }
*/
// function curry(fn) {
// // your code here
// }
function curry(func) {
return function curried(...args) {
const complete = args.length >= func.length && !args.slice(0, func.length).includes(curry.placeholder);
if(complete) {
args.length=3
args.sort((a,b)=>a-b)
return func.apply(this, args)
}
return function(...newArgs) {
// replace placeholders in args with values from newArgs
const res = [...args].filter(element=> element!== curry.placeholder);
return curried(...res, ...newArgs);
}
}
}
const join = (a, b, c) => {
return `${a}_${b}_${c}`
}
curry.placeholder = Symbol()
const curriedJoin = curry(join)
const _ = curry.placeholder
console.log(curriedJoin(1, 2, 3)) // '1_2_3'
console.log(curriedJoin(_, 2)(1, 3)) // '1_2_3'
console.log(curriedJoin(_, _, _)(1)(_, 3)(2)) // '1_2_3'
console.log(curriedJoin(_,_,3,4)(1,_)(2,5)) //Fail, because "Uncaught TypeError: curriedJoin(...)(...) is not a function"

If you add
console.log(curriedJoin(_,_,3,4)(1,_));
just before the failing line, you'll see that curriedJoin(_, _, 3, 4)(1, _) has already resolved to the string "1_3_4" ...which is not a function. Hence the error. The two versions behave quite differently (logging the various arg lists during processing is instructive.) The problem with using the "filter and append" approach is that it's not putting the args in the correct order. For the failing example, after one iteration, the 3rd placeholder ends up at the end of the arg list, beyond where the "complete" test is checking, instead of in the 2nd position where it belongs. What happens when filtering is that (_, _, 3, 4)(1, _) becomes (3,4,1,_), but the func only expects 3 good args, so this looks "complete" - oops! When using the "map" algorithm, (_, _, 3, 4)(1, _) becomes (1, _, 3, 4) which is clearly incomplete, so it goes into another recursion level as desired.

Use of .sort involves comparison of argument values and will not apply arguments with respect to their applied positions. Use of args.length = 3 will support only functions with 3 parameters.
Adding parameter n = f.length supports currying of fixed-arity functions as well as variadic functions. Adding curry.merge with sound inductive reasoning simplifies merging arguments and reduces complexity of curry.
function curry(f, n = f.length) {
return function loop(...args) {
const a = args.slice(0, n)
return a.some(v => v === curry.placeholder)
? (...b) => loop(...curry.merge(a, b))
: f(...a)
}
}
curry.placeholder = Symbol("curry.placeholder")
curry.merge = (l, r) =>
l.length == 0 && r.length == 0
? []
: l.length == 0
? r
: r.length == 0
? l
: l[0] === curry.placeholder
? [r[0], ...curry.merge(l.slice(1), r.slice(1))]
: [l[0], ...curry.merge(l.slice(1), r)]
const _ = curry.placeholder
const add = curry((a,b,c) => a + b + c)
console.log(add(1, 2, 3)) // 6
console.log(add(_, 2)(1, 3)) // 6
console.log(add(_, _, _)(1)(_, 3)(2)) // 6
console.log(add(_,_,3,4)(1,_)(2,5)) // 6
const foo = curry(console.log, 3)
foo(1, 2, 3) // 1 2 3
foo(_, 2)(1, 3) // 1 2 3
foo(_, _, _)(1)(_, 3)(2) // 1 2 3
foo(_,_,3,4)(1,_)(2,5) // 1 2 3
Maybe a better name for curry is partial as the technique you are using here is more closely related to Partial Application.

JavaScript anonymous function simulating arithmetic in lambda calculus, result returns `undefined`

I was intended to use javascript closure to simulate basic arithmetic in lambda calculus, to define 3 = 1 + 2
like this:
0 := λf.λx.x
1 := λf.λx.f x
2 := λf.λx.f (f x)
3 := λf.λx.f (f (f x))
It should print three times hello world, now it prints once hello world and twice undefined. Could someone help to explain why this happened and what's wrong about my code? Thanks in advance.
var zero = function(f) {
return function(x) {
return x;
};
};
var one = function(f) {
return function(x) {
return f(x);
};
};
function add(n, m) {
return function(f) {
return function(x) {
return n(f)(m(f)(x));
};
};
}
// test, define number two and number three in lambda calculus
var two = add(one, one);
var three = add(one, two);
// function f is to console.log
var print3times = three(value => console.log(value));
print3times("hello world")
// return:
// hello world
// undefined
// undefined

Here you go.
var log = function(x) {
console.log(x)
return x
}
var zero = function(f) {
return function(x) {
return x;
};
};
var one = function(f) {
return function(x) {
return f(x);
};
};
function add(n, m) {
return function(f) {
return function(x) {
return n(f)(m(f)(x));
};
};
}
// test, define number two and number three in lambda calculus
var two = add(one, one);
var three = add(one, two);
// function f is to console.log
var print3times = three(log);
print3times("hello world")
Here's an ES6 translation with a few bonus features for fun:
const log = x => (console.log(x), x)
const identity = x => x
const compose = f => g => x => f(g(x))
const zero = f => identity
const one = f => x => f(x)
// I took the liberty of currying add
const add = n => m => f => x => n(f)(m(f)(x))
// test, define number two and number three in lambda calculus
const addOne = add(one)
const two = addOne(one)
const three = addOne(two)
const four = compose(addOne)(addOne)(two)
// function f is to console.log
const print3times = three(log)
print3times("hello world")
four(log)('hi X 4')
Also, you may find these two youtube videos entitled "A Flock of Functions: Combinators, Lambda Calculus, & Church Encodings in JS" informative: Part 1, Part 2.

The point is that m(f)(x) in n(f)(m(f)(x)) returns undefined, since it is a console.log. Then it runs it first (and prints 'hello world'), but when running n(f) on it, it prints the result of m(f)(x): undefined.
As stated by ASDFGerte, if you add a 'return value;' to it. It will work properly.

You seem to think that three(value => console.log(value)) will do this:
function(value) {
console.log(value);
console.log(value);
console.log(value);
}
But it doesn't. It will actually do this:
function(value) {
console.log(console.log(console.log(value)));
}
In other words, your lambda calculus combinators are all fine; you're just using them wrong.

JavaScript: create function that accepts callback as input and returns function; Output depends on invoke count

The objective of my code is:
Write a function "once" that accepts a callback as input and returns a function. When the returned function is called the first time, it should call the callback and return that output. If it is called any additional times, instead of calling the callback again it will simply return the output value from the first time it was called.
I tried the code below:
const once = (inputFunc) => {
let invCount = 0;
let firstCallOutput;
return function (num) {
invCount ++;
if (invCount === 1){
firstCallOuput = inputFunc(num);
return inputFunc(num);
}
else {
return firstCallOuput;
}
}
}
const addByTwoOnce = once(function(num) {
return num + 2;
});
// UNCOMMENT THESE TO TEST YOUR WORK!
console.log(addByTwoOnce(5)); //should log 7
console.log(addByTwoOnce(10)); //should log 7
console.log(addByTwoOnce(9001)); //should log 7
My code console logs out the correct values (7) in all three situations. But it fails 2/3 test specs.
What am I doing wrong? How can I pass the two test specs?

Here's a simplified once function -
const once = (f, memo) => x =>
memo === undefined
? (memo = f(x), memo)
: memo
const addTwo = x =>
x + 2
const addTwoOnce =
once(addTwo)
console.log(addTwoOnce(5)) //should log 7
console.log(addTwoOnce(10)) //should log 7
console.log(addTwoOnce(9001)) //should log 7
If you want to safeguard the call site from being able to set the memo, you can make the memo a local variable instead of a parameter -
const once = f =>
{ let memo
return x =>
memo === undefined
? (memo = f(x), memo)
: memo
}
Or maybe you want to safeguard against the potential for the user-supplied function to return undefined. These are all choices you can make with minimal impact on the semantic structure of the code -
const once = f =>
{ let hasRun = false
let memo
return x =>
hasRun
? memo
: (hasRun = true, memo = f(x), memo)
}
Related: constant will return a constant value, regardless of its input -
const constant = x => _ =>
x
const always7 =
constant(7)
console.log(always7(5)) //should log 7
console.log(always7(10)) //should log 7
console.log(always7(9001)) //should log 7
Related: memoise will cache a value for each unique input, only recomputing f if the input has not been seen before -
const memoise = (f, memo = new Map) => x =>
memo.has(x)
? memo.get(x)
: (memo.set(x, f(x)), memo.get(x))
let fib = n =>
n < 2
? n
: fib (n - 1) + fib (n - 2)
console.time("original")
console.log(fib(40))
console.timeEnd("original")
// 1503.43 ms
fib = memoise(fib)
console.time("memoised")
console.log(fib(40))
console.timeEnd("memoised")
// 0.175 ms

Ok,
First we will create a once function that accepts a callback function.
Then we need to create a variable to check if this is the first time or not.
You can make a boolean variable or counter whatever you want. OK,
Then we make a variable result to grap the output of the callback with the initial value of 0
function once(func) {
let isOnce = true
let result = 0
}
OK, after that, let's create a function that will return the callback value if this is the first time, and if not, we will just return the output value from the first time, which we stored to the result
function once(func) {
let isOnce = true
let result = 0
function runOnce(num) {
if(isOnce) {
isOnce = false
result = func(num)
return result
} else {
return result
}
}
}
Finally, we will return the runOnce function.
function once(func) {
let isOnce = true
let result = 0
function runOnce(num) {
if(isOnce) {
isOnce = false
result = func(num)
return result
} else {
return result
}
}
return runOnce
}
Ok, now we need to create a callback function that takes the input and increments it by 2.
function addByTwo(input) {
return input + 2
}
So, time to check
const always7 = once(addByTwo);
console.log(always7(5))
console.log(always7(10))
console.log(always7(9001))
It always runs once and gets the same result every time.
the result is always be 7, click

How to conditionally assign to a variable in functional way?

I need to assign a value to a variable based on condition. I want to do it with a functional programming paradigm in mind, thus I cannot declare it in outer scope and then reassign.
// let foo = undefined // no-let!
if(condition) {
const foo = 1
} else {
const foo = 0
}
do_some_stuff(foo) // Uncaught ReferenceError: foo is not defined
I know, I can use ternary expression here like
const foo = condition ? 1 : 0
but what if I have some other routine to do inside my condition, like:
if(condition) {
const foo = 1
do_stuff()
} else {
const foo = 0
do_other_stuff()
}
do_third_stuff(foo)

Probably you would encode your case using some algebraic data type (ADT) like Either. That is, you may cover two subcases: left and right.
See the code from // --> Solution starts here onwards. Previous code is a mini standard FP library using vanilla JavaScript to make the code runnable. Check it and enjoy!
// Mini standard library
// -------------------------------
// The identity combinator
// I :: a -> a
const I = x => x
// Either ADT
const Either = (() => {
// Creates an instance of Either.Right
//
// of :: b -> Either a b
const of = x => ({ right: x })
// Creates an instance of Either.Right
//
// Right :: b -> Either a b
const Right = of
// Creates an instance of Either.Left
//
// Left :: a -> Either a b
const Left = x => ({ left: x })
// Maps Either.Left or Either.Right in a single operation
//
// bimap :: (a -> c) -> (b -> d) -> Either a b -> Either c -> d
const bimap = f => g => ({ left, right }) => left ? Left (f (left)) : Right (g (right))
// Lifts a value to Either based on a condition, where false
// results in Left, and true is Right.
//
// tagBy :: (a -> Boolean) -> a -> Either a a
const tagBy = f => x => f (x) ? Right (x) : Left (x)
// Unwraps Either.Left or Either.Right with mapping functions
//
// either :: (a -> c) -> (b -> c) -> Either a b -> c
const either = f => g => ({ left, right }) => left ? f (left) : g (right)
// Unwraps Either.Left or Either.Right and outputs the raw value on them
//
// unwrap :: Either a b -> c
const unwrap = either (I) (I)
return { of, Right, Left, bimap, tagBy, either, unwrap }
}) ()
// --> Solution starts here
// Lifts to Either.Right if x is greater than 3,
// otherwise, x is encoded as Left.
//
// tagGt3 :: Number -> Either Number Number
const tagGt3 = Either.tagBy (x => x > 3)
// doStuff :: Number -> Number
const doStuff = x => x + 1
// doStuff2 :: Number -> Number
const doStuff2 = x => x * 4
// doStuff3 :: Either Number Number -> Either Number Number
const doStuff3 = Either.bimap (doStuff) (doStuff2) // <-- here's the decision!
const eitherValue1 = doStuff3 (tagGt3 (2))
const eitherValue2 = doStuff3 (tagGt3 (30))
const output1 = Either.unwrap (eitherValue1)
const output2 = Either.unwrap (eitherValue2)
console.log ('output1: ', output1)
console.log ('output2: ', output2)
Refactor using pipes
Now I introduce pipe to glue a composition of one or more unary functions, which makes the code more elegant:
// Mini standard library
// -------------------------------
// The identity combinator
// I :: a -> a
const I = x => x
// Pipes many unary functions
//
// pipe :: [a -> b] -> a -> c
const pipe = xs => x => xs.reduce ((o, f) => f (o), x)
// Either ADT
const Either = (() => {
// Creates an instance of Either.Right
//
// of :: b -> Either a b
const of = x => ({ right: x })
// Creates an instance of Either.Right
//
// Right :: b -> Either a b
const Right = of
// Creates an instance of Either.Left
//
// Left :: a -> Either a b
const Left = x => ({ left: x })
// Maps Either.Left or Either.Right in a single operation
//
// bimap :: (a -> c) -> (b -> d) -> Either a b -> Either c -> d
const bimap = f => g => ({ left, right }) => left ? Left (f (left)) : Right (g (right))
// Lifts a value to Either based on a condition, where false
// results in Left, and true is Right.
//
// tagBy :: (a -> Boolean) -> a -> Either a a
const tagBy = f => x => f (x) ? Right (x) : Left (x)
// Unwraps Either.Left or Either.Right with mapping functions
//
// either :: (a -> c) -> (b -> c) -> Either a b -> c
const either = f => g => ({ left, right }) => left ? f (left) : g (right)
// Unwraps Either.Left or Either.Right and outputs the raw value on them
//
// unwrap :: Either a b -> c
const unwrap = either (I) (I)
return { of, Right, Left, bimap, tagBy, either, unwrap }
}) ()
// --> Solution starts here
// doStuff :: Number -> Number
const doStuff = x => x + 1
// doStuff2 :: Number -> Number
const doStuff2 = x => x * 4
const { tagBy, bimap, unwrap } = Either
// doStuff3 :: Number -> Number
const doStuff3 = pipe ([
tagBy (x => x > 3),
bimap (doStuff) (doStuff2), // <-- here's the decision!
unwrap
])
const output1 = doStuff3 (2)
const output2 = doStuff3 (30)
console.log ('output1: ', output1)
console.log ('output2: ', output2)

Nothing is stopping you from splitting the two:
const foo = condition ? 1 : 0;
if(condition) {
do_stuff();
} else {
do_other_stuff();
}
do_third_stuff(foo);
In case condition is an expensive execution, simply assign it to a variable before using it multiple times:
let isFoo = expensiveIsFooMethod();
const foo = isFoo ? 1 : 0;
if(isFoo) {
do_stuff();
} else {
do_other_stuff();
}
do_third_stuff(foo);
You're right that it would be cleaner if you didn't have to repeat the condition, but you've introduced this limitation because you're using a const variable which makes it impossible to assign a value to your const in more than one place.
I suggest outweighing the two options here. What matters to you more: cleaner syntax, or ensuring you'll never overwrite the value?

Because you dont want to declare foo outside, why you do not simply this way:
if(condition) {
const foo = 1
do_stuff()
do_third_stuff(foo)
} else {
const foo = 0
do_other_stuff()
do_third_stuff(foo)
}

How do I replace while loops with a functional programming alternative without tail call optimization?

I am experimenting with a more functional style in my JavaScript; therefore, I have replaced for loops with utility functions such as map and reduce. However, I have not found a functional replacement for while loops since tail call optimization is generally not available for JavaScript. (From what I understand ES6 prevents tail calls from overflowing the stack but does not optimize their performance.)
I explain what I have tried below, but the TLDR is:
If I don't have tail call optimization, what is the functional way to implement while loops?
What I have tried:
Creating a "while" utility function:
function while(func, test, data) {
const newData = func(data);
if(test(newData)) {
return newData;
} else {
return while(func, test, newData);
}
}
Since tail call optimization isn't available I could rewrite this as:
function while(func, test, data) {
let newData = *copy the data somehow*
while(test(newData)) {
newData = func(newData);
}
return newData;
}
However at this point it feels like I have made my code more complicated/confusing for anyone else who uses it, since I have to lug around a custom utility function. The only practical advantage that I see is that it forces me to make the loop pure; but it seems like it would be more straightforward to just use a regular while loop and make sure that I keep everything pure.
I also tried to figure out a way to create a generator function that mimics the effects of recursion/looping and then iterate over it using a utility function like find or reduce. However, I haven't figured out an readable way to do that yet.
Finally, replacing for loops with utility functions makes it more apparent what I am trying to accomplish (e.g. do a thing to each element, check if each element passes a test, etc.). However, it seems to me that a while loop already expresses what I am trying to accomplish (e.g. iterate until we find a prime number, iterate until the answer is sufficiently optimized, etc.).
So after all this, my overall question is: If I need a while loop, I am programming in a functional style, and I don't have access to tail call optimization, then what is the best strategy.

An example in JavaScript
Here's an example using JavaScript. Currently, most browsers do not support tail call optimisation and therefore the following snippet will fail
const repeat = n => f => x =>
n === 0 ? x : repeat (n - 1) (f) (f(x))
console.log(repeat(1e3) (x => x + 1) (0)) // 1000
console.log(repeat(1e5) (x => x + 1) (0)) // Error: Uncaught RangeError: Maximum call stack size exceeded
Trampolines
We can work around this limitation by changing the way we write repeat, but only slightly. Instead of returning a value directly or immediately recurring, we will return one of our two trampoline types, Bounce or Done. Then we will use our trampoline function to handle the loop.
// trampoline
const Bounce = (f,x) => ({ isBounce: true, f, x })
const Done = x => ({ isBounce: false, x })
const trampoline = ({ isBounce, f, x }) => {
while (isBounce)
({ isBounce, f, x } = f(x))
return x
}
// our revised repeat function, now stack-safe
const repeat = n => f => x =>
n === 0 ? Done(x) : Bounce(repeat (n - 1) (f), f(x))
// apply trampoline to the result of an ordinary call repeat
let result = trampoline(repeat(1e6) (x => x + 1) (0))
// no more stack overflow
console.log(result) // 1000000
Currying slows things down a little bit too, but we can remedy that using an auxiliary function for the recursion. This is nice too because it hides the trampoline implementation detail and does not expect the caller to bounce the return value. This runs about twice as fast as the above repeat
// aux helper hides trampoline implementation detail
// runs about 2x as fast
const repeat = n => f => x => {
const aux = (n, x) =>
n === 0 ? Done(x) : Bounce(x => aux (n - 1, x), f (x))
return trampoline (aux (n, x))
}
Clojure-style loop/recur
Trampolines are nice and all but it's kind of annoying to have to have to worry about calling trampoline on your function's return value. We saw the alternative was to use an auxiliary helper, but c'mon that's kind of annoying, too. I'm sure some of you aren't too keen about the Bounce and Done wrappers, too.
Clojure creates a specialised trampoline interface that uses a pair of functions, loop and recur – this tandem pair lends itself to a remarkably elegant expression of a program
Oh and it's really fast, too
const recur = (...values) =>
({ recur, values })
const loop = run =>
{ let r = run ()
while (r && r.recur === recur)
r = run (...r.values)
return r
}
const repeat = n => f => x =>
loop
( (m = n, r = x) =>
m === 0
? r
: recur (m - 1, f (r))
)
console.time ('loop/recur')
console.log (repeat (1e6) (x => x + 1) (0)) // 1000000
console.timeEnd ('loop/recur') // 24 ms
Initially this style will feel foreign, but over time I am finding it to be the most consistent while producing durable programs. Comments below help ease you into the expression-rich syntax -
const repeat = n => f => x =>
loop // begin a loop with
( ( m = n // local loop var m: counter, init with n
, r = x // local loop var r: result, init with x
) =>
m === 0 // terminating condition
? r // return result
: recur // otherwise recur with
( m - 1 // next m value
, f (r) // next r value
)
)
The continuation monad
This is one of my favourite topics tho, so we're gonna see what this looks like with the continuation monad. Reusing loop and recur, we implement a stack-safe cont that can sequence operations using chain and run operation sequences using runCont. For repeat, this is senseless (and slow), but it's cool to see the mechanics of cont at work in this simple example -
const identity = x =>
x
const recur = (...values) =>
({ recur, values })
const loop = run =>
{ let r = run ()
while (r && r.recur === recur)
r = run (...r.values)
return r
}
// cont : 'a -> 'a cont
const cont = x =>
k => recur (k, x)
// chain : ('a -> 'b cont) -> 'a cont -> 'b cont
const chain = f => mx =>
k => recur (mx, x => recur (f (x), k))
// runCont : ('a -> 'b) -> a cont -> 'b
const runCont = f => mx =>
loop ((r = mx, k = f) => r (k))
const repeat = n => f => x =>
{ const aux = n => x =>
n === 0 // terminating condition
? cont (x) // base case, continue with x
: chain // otherise
(aux (n - 1)) // sequence next operation on
(cont (f (x))) // continuation of f(x)
return runCont // run continuation
(identity) // identity; pass-thru
(aux (n) (x)) // the continuation returned by aux
}
console.time ('cont monad')
console.log (repeat (1e6) (x => x + 1) (0)) // 1000000
console.timeEnd ('cont monad') // 451 ms
Y combinator
The Y combinator is my spirit combinator; this answer would be incomplete without giving it some place amongst the other techniques. Most implementations of the Y combinator however, are not stack-safe and will overflow if the user-supplied function recurs too many times. Since this answer is all about preserving stack-safe behaviour, of course we'll implement Y in a safe way – again, relying on our trusty trampoline.
Y demonstrates the ability to extend easy-to-use, stack-safe, synchronous infinite recursion without cluttering up your function.
const bounce = f => (...xs) =>
({ isBounce: true, f, xs })
const trampoline = t => {
while (t && t.isBounce)
t = t.f(...t.xs)
return t
}
// stack-safe Y combinator
const Y = f => {
const safeY = f =>
bounce((...xs) => f (safeY (f), ...xs))
return (...xs) =>
trampoline (safeY (f) (...xs))
}
// recur safely to your heart's content
const repeat = Y ((recur, n, f, x) =>
n === 0
? x
: recur (n - 1, f, f (x)))
console.log(repeat (1e5, x => x + 1, 0)) // 10000
Practicality with while loop
But let's be honest: that's a lot of ceremony when we're overlooking one of the more obvious potential solutions: use a for or while loop, but hide it behind a functional interface
For all intents and purposes, this repeat function works identically to the ones provided above – except this one is about one or two gadzillion times faster (with exception to the loop/recur solution). Heck, it's arguably a lot easier to read too.
Granted, this function is perhaps a contrived example – not all recursive functions can be converted to a for or while loop so easily, but in such a scenario where it's possible, it's probably best to just do it like this. Save the trampolines and continuations for heavy lifting when a simple loop won't do.
const repeat = n => f => x => {
let m = n
while (true) {
if (m === 0)
return x
else
(m = m - 1, x = f (x))
}
}
const gadzillionTimes = repeat(1e8)
const add1 = x => x + 1
const result = gadzillionTimes (add1) (0)
console.log(result) // 100000000
setTimeout is NOT a solution to the stack overflow problem
OK, so it does work, but only paradoxically. If your dataset is small, you don't need setTimeout because there will be no stack overflow. If your dataset is large and you use setTimeout as a safe recursion mechanism, not only do you make it impossible to synchronously return a value from your function, it will be so F slow you won't even want to use your function
Some people have found an interview Q&A prep site that encourages this dreadful strategy
What our repeat would look like using setTimeout – notice it's also defined in continuation passing style – ie, we must call repeat with a callback (k) to get the final value
// do NOT implement recursion using setTimeout
const repeat = n => f => x => k =>
n === 0
? k (x)
: setTimeout (x => repeat (n - 1) (f) (x) (k), 0, f (x))
// be patient, this one takes about 5 seconds, even for just 1000 recursions
repeat (1e3) (x => x + 1) (0) (console.log)
// comment the next line out for absolute madness
// 10,000 recursions will take ~1 MINUTE to complete
// paradoxically, direct recursion can compute this in a few milliseconds
// setTimeout is NOT a fix for the problem
// -----------------------------------------------------------------------------
// repeat (1e4) (x => x + 1) (0) (console.log)
I can't stress enough how bad this is. Even 1e5 takes so long to run that I gave up trying to measure it. I'm not including this in the benchmarks below because it's just too slow to even be considered a viable approach.
Promises
Promises have the ability to chain computations and are stack safe. However, achieving a stack-safe repeat using Promises means we'll have to give up our synchronous return value, the same way we did using setTimeout. I'm providing this as a "solution" because it does solve the problem, unlike setTimeout, but in a way that's very simple compared to the trampoline or continuation monad. As you might imagine though, the performance is somewhat bad, but nowhere near as bad as the setTimeout example above
Worth noting in this solution, the Promise implementation detail is completely hidden from the caller. A single continuation is provided as a 4th argument and its called when the computation is complete.
const repeat = n => f => x => k =>
n === 0
? Promise.resolve(x).then(k)
: Promise.resolve(f(x)).then(x => repeat (n - 1) (f) (x) (k))
// be patient ...
repeat (1e6) (x => x + 1) (0) (x => console.log('done', x))
Benchmarks
Seriously, the while loop is a lot faster - like almost 100x faster (when comparing best to worst – but not including async answers: setTimeout and Promise)
// sync
// -----------------------------------------------------------------------------
// repeat implemented with basic trampoline
console.time('A')
console.log(tramprepeat(1e6) (x => x + 1) (0))
console.timeEnd('A')
// 1000000
// A 114 ms
// repeat implemented with basic trampoline and aux helper
console.time('B')
console.log(auxrepeat(1e6) (x => x + 1) (0))
console.timeEnd('B')
// 1000000
// B 64 ms
// repeat implemented with cont monad
console.time('C')
console.log(contrepeat(1e6) (x => x + 1) (0))
console.timeEnd('C')
// 1000000
// C 33 ms
// repeat implemented with Y
console.time('Y')
console.log(yrepeat(1e6) (x => x + 1) (0))
console.timeEnd('Y')
// 1000000
// Y 544 ms
// repeat implemented with while loop
console.time('D')
console.log(whilerepeat(1e6) (x => x + 1) (0))
console.timeEnd('D')
// 1000000
// D 4 ms
// async
// -----------------------------------------------------------------------------
// repeat implemented with Promise
console.time('E')
promiserepeat(1e6) (x => x + 1) (0) (console.log)
console.timeEnd('E')
// 1000000
// E 2224 ms
// repeat implemented with setTimeout; FAILED
console.time('F')
timeoutrepeat(1e6) (x => x + 1) (0) (console.log)
console.timeEnd('F')
// ...
// too slow; didn't finish after 3 minutes
Stone Age JavaScript
The above techniques are demonstrated using newer ES6 syntaxes, but you could implement a trampoline in the earliest possible version of JavaScript – it only requires while and first class functions
Below, we use stone age javascript to demonstrate infinite recursion is possible and performant without necessarily sacrificing a synchronous return value – 100,000,000 recursions in under 6 seconds - this is a dramatic difference compared to setTimeout which can only 1,000 recursions in the same amount of time.
function trampoline (t) {
while (t && t.isBounce)
t = t.f (t.x);
return t.x;
}
function bounce (f, x) {
return { isBounce: true, f: f, x: x };
}
function done (x) {
return { isBounce: false, x: x };
}
function repeat (n, f, x) {
function aux (n, x) {
if (n === 0)
return done (x);
else
return bounce (function (x) { return aux (n - 1, x); }, f (x));
}
return trampoline (aux (n, x));
}
console.time('JS1 100K');
console.log (repeat (1e5, function (x) { return x + 1 }, 0));
console.timeEnd('JS1 100K');
// 100000
// JS1 100K: 15ms
console.time('JS1 100M');
console.log (repeat (1e8, function (x) { return x + 1 }, 0));
console.timeEnd('JS1 100M');
// 100000000
// JS1 100K: 5999ms
Non-blocking infinite recursion using stone age JavaScript
If, for some reason, you want non-blocking (asynchronous) infinite recursion, we can rely on setTimeout to defer a single frame at the start of the computation. This program also uses stone age javascript and computes 100,000,000 recursions in under 8 seconds, but this time in a non-blocking way.
This demonstrates that there's nothing special about having a non-blocking requirement. A while loop and first-class functions are still the only fundamental requirement to achieve stack-safe recursion without sacrificing performance
In a modern program, given Promises, we would substitute the setTimeout call for a single Promise.
function donek (k, x) {
return { isBounce: false, k: k, x: x };
}
function bouncek (f, x) {
return { isBounce: true, f: f, x: x };
}
function trampolinek (t) {
// setTimeout is called ONCE at the start of the computation
// NOT once per recursion
return setTimeout(function () {
while (t && t.isBounce) {
t = t.f (t.x);
}
return t.k (t.x);
}, 0);
}
// stack-safe infinite recursion, non-blocking, 100,000,000 recursions in under 8 seconds
// now repeatk expects a 4th-argument callback which is called with the asynchronously computed result
function repeatk (n, f, x, k) {
function aux (n, x) {
if (n === 0)
return donek (k, x);
else
return bouncek (function (x) { return aux (n - 1, x); }, f (x));
}
return trampolinek (aux (n, x));
}
console.log('non-blocking line 1')
console.time('non-blocking JS1')
repeatk (1e8, function (x) { return x + 1; }, 0, function (result) {
console.log('non-blocking line 3', result)
console.timeEnd('non-blocking JS1')
})
console.log('non-blocking line 2')
// non-blocking line 1
// non-blocking line 2
// [ synchronous program stops here ]
// [ below this line, asynchronous program continues ]
// non-blocking line 3 100000000
// non-blocking JS1: 7762ms

A better loop/recur pattern
There are two things that I dislike about the loop/recur pattern described in the accepted answer. Note that I actually like the idea behind the loop/recur pattern. However, I dislike the way it has been implemented. So, let's first look at the way I would have implemented it.
// Recur :: a -> Result a b
const Recur = (...args) => ({ recur: true, args });
// Return :: b -> Result a b
const Return = value => ({ recur: false, value });
// loop :: (a -> Result a b) -> a -> b
const loop = func => (...args) => {
let result = func(...args);
while (result.recur) result = func(...result.args);
return result.value;
};
// repeat :: (Int, a -> a, a) -> a
const repeat = loop((n, f, x) => n === 0 ? Return(x) : Recur(n - 1, f, f(x)));
console.time("loop/recur/return");
console.log(repeat(1e6, x => x + 1, 0));
console.timeEnd("loop/recur/return");
Compare this with the loop/recur pattern described in the aforementioned answer.
// recur :: a -> Recur a
const recur = (...args) => ({ recur, args });
// loop :: (a? -> Recur a ∪ b) -> b
const loop = func => {
let result = func();
while (result && result.recur === recur) result = func(...result.args);
return result;
};
// repeat :: (Int, a -> a, a) -> a
const repeat = (n, f, x) => loop((m = n, r = x) => m === 0 ? r : recur(m - 1, f(r)));
console.time("loop/recur");
console.log(repeat(1e6, x => x + 1, 0));
console.timeEnd("loop/recur");
If you notice, the type signature of the second loop function uses default parameters (i.e. a?) and untagged unions (i.e. Recur a ∪ b). Both of these features are at odds with the functional programming paradigm.
Problem with default parameters
The loop/recur pattern in the aforementioned answer uses default parameters to supply the initial arguments of the function. I think this is an abuse of default parameters. You can just as easily supply initial arguments using my version of loop.
// repeat :: (Int, a -> a, a) -> a
const repeat = (n, f, x) => loop((n, x) => n === 0 ? Return(x) : Recur(n - 1, f(x)))(n, x);
// or more readable
const repeat = (n, f, x) => {
const repeatF = loop((n, x) => n === 0 ? Return(x) : Recur(n - 1, f(x)));
return repeatF(n, x);
};
Futhermore, it allows eta conversion when the all the arguments are passed through.
// repeat :: (Int, a -> a, a) -> a
const repeat = (n, f, x) => loop((n, f, x) => n === 0 ? Return(x) : Recur(n - 1, f, f(x)))(n, f, x);
// can be η-converted to
const repeat = loop((n, f, x) => n === 0 ? Return(x) : Recur(n - 1, f, f(x)));
Using the version of loop with default parameters does not allow eta conversion. In addition, it forces you to rename parameters because you can't write (n = n, x = x) => ... in JavaScript.
Problem with untagged unions
Untagged unions are bad because they erase important information, i.e. information of where the data came from. For example, because my Result type is tagged I can distinguish Return(Recur(0)) from Recur(0).
On the other hand, because the right-hand side variant of Recur a ∪ b is untagged, if b is specialized to Recur a, i.e. if the type is specialized to Recur a ∪ Recur a, then it's impossible to determine whether the Recur a came from the left-hand side or the right-hand side.
One criticism might be that b will never be specialized to Recur a, and hence it doesn't matter that b is untagged. Here's a simple counterexample to that criticism.
// recur :: a -> Recur a
const recur = (...args) => ({ recur, args });
// loop :: (a? -> Recur a ∪ b) -> b
const loop = func => {
let result = func();
while (result && result.recur === recur) result = func(...result.args);
return result;
};
// repeat :: (Int, a -> a, a) -> a
const repeat = (n, f, x) => loop((m = n, r = x) => m === 0 ? r : recur(m - 1, f(r)));
// infinite loop
console.log(repeat(1, x => recur(1, x), "wow, such hack, much loop"));
// unreachable code
console.log("repeat wasn't hacked");
Compare this with my version of repeat which is bulletproof.
// Recur :: a -> Result a b
const Recur = (...args) => ({ recur: true, args });
// Return :: b -> Result a b
const Return = value => ({ recur: false, value });
// loop :: (a -> Result a b) -> a -> b
const loop = func => (...args) => {
let result = func(...args);
while (result.recur) result = func(...result.args);
return result.value;
};
// repeat :: (Int, a -> a, a) -> a
const repeat = loop((n, f, x) => n === 0 ? Return(x) : Recur(n - 1, f, f(x)));
// finite loop
console.log(repeat(1, x => Recur(1, x), "wow, such hack, much loop"));
// reachable code
console.log("repeat wasn't hacked");
Thus, untagged unions are unsafe. However, even if we were careful to avoid the pitfalls of untagged unions I would still prefer tagged unions because the tags provide useful information when reading and debugging the program. IMHO, the tags make the program more understandable and easier to debug.
Conclusion
To quote the Zen of Python.
Explicit is better than implicit.
Default parameters and untagged unions are bad because they are implicit, and can lead to ambiguities.
The Trampoline monad
Now, I'd like to switch gears and talk about monads. The accepted answer demonstrates a stack-safe continuation monad. However, if you only need to create a monadic stack-safe recursive function then you don't need the full power of the continuation monad. You can use the Trampoline monad.
The Trampoline monad is a more powerful cousin of the Loop monad, which is just the loop function converted into a monad. So, let's start by understanding the Loop monad. Then we'll see the main problem of the Loop monad and how the Trampoline monad can be used to fix that problem.
// Recur :: a -> Result a b
const Recur = (...args) => ({ recur: true, args });
// Return :: b -> Result a b
const Return = value => ({ recur: false, value });
// Loop :: (a -> Result a b) -> a -> Loop b
const Loop = func => (...args) => ({ func, args });
// runLoop :: Loop a -> a
const runLoop = ({ func, args }) => {
let result = func(...args);
while (result.recur) result = func(...result.args);
return result.value;
};
// pure :: a -> Loop a
const pure = Loop(Return);
// bind :: (Loop a, a -> Loop b) -> Loop b
const bind = (loop, next) => Loop(({ first, loop: { func, args } }) => {
const result = func(...args);
if (result.recur) return Recur({ first, loop: { func, args: result.args } });
if (first) return Recur({ first: false, loop: next(result.value) });
return result;
})({ first: true, loop });
// ack :: (Int, Int) -> Loop Int
const ack = (m, n) => {
if (m === 0) return pure(n + 1);
if (n === 0) return ack(m - 1, 1);
return bind(ack(m, n - 1), n => ack(m - 1, n));
};
console.log(runLoop(ack(3, 4)));
Note that loop has been split into a Loop and a runLoop function. The data structure returned by Loop is a monad, and the pure and bind functions implement its monadic interface. We use the pure and bind functions to write a straightforward implementation of the Ackermann function.
Unfortunately, the ack function is not stack safe because it recursively calls itself until it reaches a pure value. Instead, we would like ack to return a Recur like data structure for its inductive cases. However, Recur values are of type Result instead of Loop. This problem is solved by the Trampoline monad.
// Bounce :: (a -> Trampoline b) -> a -> Trampoline b
const Bounce = func => (...args) => ({ bounce: true, func, args });
// Return :: a -> Trampoline a
const Return = value => ({ bounce: false, value });
// trampoline :: Trampoline a -> a
const trampoline = result => {
while (result.bounce) result = result.func(...result.args);
return result.value;
};
// pure :: a -> Trampoline a
const pure = Return;
// bind :: (Trampoline a, a -> Trampoline b) -> Trampoline b
const bind = (first, next) => first.bounce ?
Bounce(args => bind(first.func(...args), next))(first.args) :
next(first.value);
// ack :: (Int, Int) -> Trampoline Int
const ack = Bounce((m, n) => {
if (m === 0) return pure(n + 1);
if (n === 0) return ack(m - 1, 1);
return bind(ack(m, n - 1), n => ack(m - 1, n));
});
console.log(trampoline(ack(3, 4)));
The Trampoline data type is a combination of Loop and Result. The Loop and Recur data constructors have been combined into a single Bounce data constructor. The runLoop function has been simplified and renamed to trampoline. The pure and bind functions have also been simplified. In fact, pure is just Return. Finally, we apply Bounce to the original implementation of the ack function.
Another advantage of Trampoline is that it can be used to define stack-safe mutually recursive functions. For example, here's an implementation of the Hofstadter Female and Male sequence functions.
// Bounce :: (a -> Trampoline b) -> a -> Trampoline b
const Bounce = func => (...args) => ({ bounce: true, func, args });
// Return :: a -> Trampoline a
const Return = value => ({ bounce: false, value });
// trampoline :: Trampoline a -> a
const trampoline = result => {
while (result.bounce) result = result.func(...result.args);
return result.value;
};
// pure :: a -> Trampoline a
const pure = Return;
// bind :: (Trampoline a, a -> Trampoline b) -> Trampoline b
const bind = (first, next) => first.bounce ?
Bounce(args => bind(first.func(...args), next))(first.args) :
next(first.value);
// female :: Int -> Trampoline Int
const female = Bounce(n => n === 0 ? pure(1) :
bind(female(n - 1), f =>
bind(male(f), m =>
pure(n - m))));
// male :: Int -> Trampoline Int
const male = Bounce(n => n === 0 ? pure(0) :
bind(male(n - 1), m =>
bind(female(m), f =>
pure(n - f))));
console.log(Array.from({ length: 21 }, (_, n) => trampoline(female(n))).join(" "));
console.log(Array.from({ length: 21 }, (_, n) => trampoline(male(n))).join(" "));
The major pain point of writing monadic code is callback hell. However, this can be solved using generators.
// Bounce :: (a -> Trampoline b) -> a -> Trampoline b
const Bounce = func => (...args) => ({ bounce: true, func, args });
// Return :: a -> Trampoline a
const Return = value => ({ bounce: false, value });
// trampoline :: Trampoline a -> a
const trampoline = result => {
while (result.bounce) result = result.func(...result.args);
return result.value;
};
// pure :: a -> Trampoline a
const pure = Return;
// bind :: (Trampoline a, a -> Trampoline b) -> Trampoline b
const bind = (first, next) => first.bounce ?
Bounce(args => bind(first.func(...args), next))(first.args) :
next(first.value);
// bounce :: (a -> Generator (Trampoline b)) -> a -> Trampoline b
const bounce = func => Bounce((...args) => {
const gen = func(...args);
const next = data => {
const { value, done } = gen.next(data);
return done ? value : bind(value, next);
};
return next(undefined);
});
// female :: Int -> Trampoline Int
const female = bounce(function* (n) {
return pure(n ? n - (yield male(yield female(n - 1))) : 1);
});
// male :: Int -> Trampoline Int
const male = bounce(function* (n) {
return pure(n ? n - (yield female(yield male(n - 1))) : 0);
});
console.log(Array.from({ length: 21 }, (_, n) => trampoline(female(n))).join(" "));
console.log(Array.from({ length: 21 }, (_, n) => trampoline(male(n))).join(" "));
Finally, mutually recursive functions also demonstrate the advantage of having a separate trampoline function. It allows us to call a function returning a Trampoline value without actually running it. This allows us to build bigger Trampoline values, and then run the entire computation when required.
Conclusion
If you're want to write indirectly or mutually recursive stack-safe functions, or monadic stack-safe functions then use the Trampoline monad. If you want to write non-monadic directly recursive stack-safe functions then use the loop/recur/return pattern.

Programming in the sense of the functional paradigm means that we are guided by types to express our algorithms.
To transform a tail recursive function into a stack-safe version we have to consider two cases:
base case
recursive case
We have to make a choice and this goes well with tagged unions. However, Javascript doesn't have such a data type so either we have to create one or fall back to Object encodings.
Object Encoded
// simulate a tagged union with two Object types
const Loop = x =>
({value: x, done: false});
const Done = x =>
({value: x, done: true});
// trampoline
const tailRec = f => (...args) => {
let step = Loop(args);
do {
step = f(Loop, Done, step.value);
} while (!step.done);
return step.value;
};
// stack-safe function
const repeat = n => f => x =>
tailRec((Loop, Done, [m, y]) => m === 0
? Done(y)
: Loop([m - 1, f(y)])) (n, x);
// run...
const inc = n =>
n + 1;
console.time();
console.log(repeat(1e6) (inc) (0));
console.timeEnd();
Function Encoded
Alternatively, we can create a real tagged union with a function encoding. Now our style is much closer to mature functional languages:
// type/data constructor
const Type = Tcons => (tag, Dcons) => {
const t = new Tcons();
t.run = cases => Dcons(cases);
t.tag = tag;
return t;
};
// tagged union specific for the case
const Step = Type(function Step() {});
const Done = x =>
Step("Done", cases => cases.Done(x));
const Loop = args =>
Step("Loop", cases => cases.Loop(args));
// trampoline
const tailRec = f => (...args) => {
let step = Loop(args);
do {
step = f(step);
} while (step.tag === "Loop");
return step.run({Done: id});
};
// stack-safe function
const repeat = n => f => x =>
tailRec(step => step.run({
Loop: ([m, y]) => m === 0 ? Done(y) : Loop([m - 1, f(y)]),
Done: y => Done(y)
})) (n, x);
// run...
const inc = n => n + 1;
const id = x => x;
console.log(repeat(1e6) (inc) (0));

See also unfold which (from Ramda docs)
Builds a list from a seed value. Accepts an iterator function, which
returns either false to stop iteration or an array of length 2
containing the value to add to the resulting list and the seed to be
used in the next call to the iterator function.
var r = n => f => x => x > n ? false : [x, f(x)];
var repeatUntilGreaterThan = n => f => R.unfold(r(n)(f), 1);
console.log(repeatUntilGreaterThan(10)(x => x + 1));
<script src="https://cdnjs.cloudflare.com/ajax/libs/ramda/0.22.1/ramda.min.js"></script>

I've been thinking about this question a lot. Recently I came across the need for a functional while loop.
It seems to me like the only thing this question really wants is a way to inline a while loop. There IS a way to do that using a closure.
"some string "+(a=>{
while(comparison){
// run code
}
return result;
})(somearray)+" some more"
Alternatively, if what you want is something that chains off an array, than you can use the reduce method.
somearray.reduce((r,o,i,a)=>{
while(comparison){
// run code
}
a.splice(1); // This would ensure only one call.
return result;
},[])+" some more"
None of this actually turns our while loop at its core into a function. But it does allow us the use of an inline loop. And I just wanted to share this with anyone who this might help.