On Fri, Dec 18, 2009 at 1:15 PM, Dan Bron <[email protected]> wrote: > Put another way, a suitably structured array means you have to design your > code the right way in the first place. Rewriting $: as ^: means you have > to design your code the right way in the first place, then change it because > the right way is broken.
I am not sure I agree here. The overlap between $: and ^: is roughly analogous to the overlap between ^: and / or maybe the overlap between *. and 1 b. There are many contexts and domais where you can accomplish the same thing with different expressions, but that does not mean that the primitives in those expressions need to change specifically for those contexts. Of course "lack of need" does not equate to "must not happen", but a demonstrated need would help in setting priorities. > Put another way, how do you think a Lisper would react to being > told that "recursion is isomorphic to a loop plus a stack, so just > 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. Of course, people with existing programs would not want to rewrite their old code, but that's always the case. 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. > Why so many functional languages put so much emphasis > on efficient recursion? A lot of that is tradition. Full recursion is overkill for almost all computable problems. > Put another way, why do you think there are people in the > world who utter statements like "Recursion defines your > worth as a human being" [1]? (Besides "people are weird.", > which is true.) Chutzpah. > Put another way, I *already* spell $: as ^: . As I said, I > am leery of $: so I try to find a clean, natural way of expressing > the same notions using ^: in the first place. This is what > you're suggesting I do, except that I am skipping the superfluous > step of writing (or designing, or thinking about) the problem in > terms of $: first. But that's a shame, because many problems are > clearly and naturally expressed recursively, but the part of my mind > that thinks that way atrophies for lack of use. So this flaw > in the interpreter has a detrimental effect upon the notation (as > a tool of thought). And, here, I think, is a pretty nice description of why people use recursion instead of other mechanisms. They do not use those other mechanisms so they do not think that way. > Now, to be fair, there are other reasons I avoid $: [2] so > and those reasons might contribute more to my perception > of that verb than the stack errors I've encountered. Ok. > Also, you might be saying that optimizing tails calls wouldn't > necessarily avoid those stack errors, because there are is a larger, > more common class of recursive calls that are harder to optimize. > I'll buy that, but (A) that doesn't mean we should avoid > improving the interpreter in the cases we know we can and > (B) there might be (non-TCO) approaches to optimizing that > larger class, and I would enjoy it if the interpreter attempted some > of these (I assume, but do not know, that these are covered in > literature and practice in the wider functional programming world). How would you model this, in J? > How to prioritize these optimizations is a different question, but let's not > be conservative for its own sake. I was thinking that this thread would go in the direction of identifying some class of problems which "trivially recognizable as tail recursive" but not "trivially convertable to ^: form". But I can not think of any examples of this. Instead, most of this tangent has been rhetorical in character. > [1] http://www.jsoftware.com/pipermail/programming/2009-December/017341.html As an aside, note that I have not attempted any solutions of that problem in part because most of the implementation complexities implementation seem to me to be silly. (In my professional experience its better to push back on that kind of specification than it is to try to implement it, regardless of the implementation language.) ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
