Raul wrote: > I do not see how [expressing $: in terms of ^:] is > any more of a detail than arranging for your data > to be in a suitably structured array.
Because it involves rewriting code to work around a limitation? Because the natural expression of a large class of algorithms is untrustworthy? 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. 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"? Why so many functional languages put so much emphasis on efficient recursion? 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.) 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). 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. 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 to prioritize these optimizations is a different question, but let's not be conservative for its own sake. -Dan [1] http://www.jsoftware.com/pipermail/programming/2009-December/017341.html [2] In particular, I prefer fully fixable tacit verbs, and $: doesn't lend itself to this style, for notational reasons unrelated to stack depth. See http://www.jsoftware.com/pipermail/programming/2009-August/016111.html for an example. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
