DB=me, Raul is quoted otherwise > The overlap between $: and ^: is roughly analogous to the overlap > between ^: and / or maybe the overlap between *. and 1 b.
Yes, and I am glad there are options. I do not want my options artificially limited. But, of course, I will accept limited options for good reasons (for example, if the cost or opportunity cost of un-limiting them is high). > Of course "lack of need" does not equate to "must not happen", > but a demonstrated need would help in setting priorities. So far, no one has led me to believe removing this limitation is anything but trivial. If the cost is low, then so is the need for justification. DB> Put another way, how do you think a Lisper would react to being DB> told that "recursion is isomorphic to a loop plus a stack, so just DB> rewrite your code that way"? > That would depend on how this was presented to the Lisper. > If it was presented in a nice glossy lisp-like way, I imagine a > lot of Lispers would happily spend years developing and exploring > the idea. You mean, if the details of it were glossed over, and it were available as a built-in construct, so the Lisper didn't have to craft it by hand each time? I see analogies here. > Meanwhile, a problem with "tail recursion" can be that you > get subtle and obscure performance crashes when you use > expressions which the interpreter does not classify as > tail recursion. As opposed to getting blatant and obscure performance crashes because the interpreter doesn't classify anything as tail recursion? > Why so many functional languages put so much emphasis > on efficient recursion? > Full recursion is overkill for almost all computable > problems. I would not use full recursion for all computable problems. I would use it where it makes expressing a computable problem easy and clear, and where equivalent expressions using other mechanisms would be less easy and clear. DB> why do you think there are people in the world who utter statements like DB> "Recursion defines your worth as a human being > Chutzpah. Fair. Now, how to you account for the sentiment that motivated the statement? What made the audacious professor feel that way about recursion? DB> Also, you might be saying that optimizing tails calls wouldn't DB> necessarily avoid those stack errors [...] there might be (non-TCO) DB> approaches to optimizing that larger class DB > (I assume, but do not know, that these are covered in DB > literature and practice in the wider functional programming world). > How would you model this, in J? Model what, specifically? This paragraph was more a question than a statement. The question was: do you (Raul specifically, but anyone generally) dispute that a non-negligible proportion of recursion-prompted stack errors would be evaded by a TCO J interpreter? If no, or you don't know, or don't understand the question, etc, then the rest of the paragraph is irrelevant. If yes (you dispute it), then I would welcome discussion of that topic, but as I noted, I can offer no advice (or J models). > As an aside, note that I have not attempted any solutions of that > problem in part because most of the implementation complexities > seem to me to be silly. [...] In my professional experience its better > to push back on that kind of specification Agreed, but of course RC isn't a venue for professional programming (though professional programmers may contribute to it). It can be silly, and silly can be fun. -Dan ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
