Tail recursion, but modulo cons
&gt; Yeah, if you run this function, you will notice that the result is in the reverse order of what they should be ([ 3, 2, 1 ] instead of [ 1, 2, 3 ] for instance). And that’s because the last x will be at the very start of the accumulator, and inversely the first x will be at the very end.<p>&gt; So… we’ll just add a small List.reverse on the accumulator at the very end… It will hurt performance quite a bit but correctness is more important.<p>&gt; Surely we can do better than this, right?! Let’s take a look at how List.map is implemented in the core library.<p>&gt; That’s surprisingly simple. The order is right because the list is being visited in reverse order (that’s what foldr does, in contrast to foldl). But we need to look at the implementation of List.foldr to see if we can reuse the same idea for our custom functioOH GOD CLOSE THE TAB!<p>&gt; Ugh… if you’ve opened the link, you know that we have gone far from the elegant solution described at the beginning.<p>But List.foldr is using almost exactly the same strategy that is considered and rejected in the early draft of mapHelper. Visit the list in reverse order and then reverse the result. (Technically, reverse the input list and then visit it in reverse order, instead of visiting the input list in reverse order and then reversing the output. foldr&#x27;s output isn&#x27;t a list.)<p>The only difference is that List.foldr will visit the first ~2000 elements of the list in correct order, just in case, and if the list is still going it will give up and reverse it at that point.<p>How far is that from the solution described at the beginning?