# Avoiding "RangeError: Maximum call stack size exceeded"

**URL:** <https://discourse.elm-lang.org/t/avoiding-rangeerror-maximum-call-stack-size-exceeded/8023>\
**Category:** Learn\
**Created:** [December 26, 2021, 3:02pm UTC](https://discourse.elm-lang.org/t/avoiding-rangeerror-maximum-call-stack-size-exceeded/8023 "2021-12-26T15:02:40Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\
**Post date:** [December 27, 2021, 11:21am UTC](https://discourse.elm-lang.org/t/avoiding-rangeerror-maximum-call-stack-size-exceeded/8023/7 "2021-12-27T11:21:59Z")

</div>

Is ‘tail call modulo cons’ implemented in elm-optimize-level-2? I saw some comments around that in the thread linked below. Not sure if level-2 would be a convenient place to implement that, maybe needs to be in the compiler.

> [@A faster \`List.map\` for Elm](https://discourse.elm-lang.org/t/a-faster-list-map-for-elm/6721):
>
> I just ran some benchmarks on an alternative List.map implementation in JavaScript and it looks really fast! There’s an old LISP trick from the 70’s called [“tail recursion modulo cons”](https://en.wikipedia.org/wiki/Tail_call#Tail_recursion_modulo_cons) that allows you to optimise certain linked list functions that are “not quite” tail recursive. “Not quite” in this case means they do a “cons” before the tail call. The trick allows you to get around that and turn it into a while loop as the compiler does for proper tail recursive functions. @jreusch [mentioned t…](https://discourse.elm-lang.org/t/elm-core-libs-in-webassembly/4443/11)

---

_[View the full topic](https://discourse.elm-lang.org/t/avoiding-rangeerror-maximum-call-stack-size-exceeded/8023)._