Is do_foo actually common for tail recursive implementations though?
Ultimately functions are not identified by name - they are identified by the combination of name and arity i.e. foo/1 and foo/2 are already different functions. Adopting either do_foo or _foo is equivalent to going down the Hungarian Notation rabbit hole - (many people would argue that if you need type/protection hints then use an IDE rather than burying that information in the function name).
So I’m more familiar with the foo/1 and foo/2 convention to highlight that these distinct functions are part of the same functionality behind the foo name.
I think there is some conflation going on here.
-
Being tail recursive and having private access is orthogonal. They may coincide with your choice of implementation. Alternately in Erlang it’s the public function that has to be exported i.e. all functions are private by default.
-
That “extra parameter” tends to be a differentiator between implementing body or tail recursion.
- Body recursion leaves intermediate results on the call stack.
- Tail recursion explicitly takes control of the “bag of intermediate results” so that it does need to leave additional data on the call stack. So that “extra parameter” is the “bag of intermediate results” that the tail recursion explicitly manages - in a way a faux call stack.
Edit: Changed “stack of intermediate results” to “bag of intermediate results” i.e. holder of intermediate data with whatever internal structure is appropriate to solving the problem.
