[chowells]

"go" is a fantastic name for communicating that all you're doing is exactly what the containing named definition promises. It's a lot better than adding "Worker" or "Impl" as a suffix of the same name as the parent. It contains no additional information because there's no additional information to contain - the parent name already says it all. So you might as well make it short and a standard idiom.

[wnoise]

You're not doing what the parent definition promises though -- if you were you'd leave out the parent definition and the where, and just write the go definition with the true name.

Go is instead doing something similar to the parent that is easily transformed to the right thing (i.e. accumulated in reverse or something), or more general that does the right thing when called with specific arguments. Communicating how and why the function does what it does and works in conjunction with the top level wrapper actually matters.

[chowells]

Yes, you're doing what the parent promises. You're setting up some initial values for internal accumulators and closing over values that don't change in preparation for the loop. Then maybe you do a bit of cleanup after the loop.

But it's no more interesting than a "for" or "while" loop that takes up most of the body of a function in C or Java. People don't demand descriptive names for those, because they realize such a name would contain no useful information. That's equally true in functional programming.