On Fri, Dec 18, 2009 at 4:35 PM, Dan Bron <[email protected]> wrote: > 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.
If it is trivial then a model implementation in J would also be trivial. I have not seen any such model implementations in J. Have I overlooked something? > 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? No. I meant if the idea were marketed properly, so that Lispers would feel good about crafting it by hand. > As opposed to getting blatant and obscure performance crashes > because the interpreter doesn't classify anything as tail recursion? That is the general case of 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. Even there, I imagine primitive recursion would be sufficient in almost all cases. > Fair. Now, how to you account for the sentiment that motivated > the statement? What made the audacious professor feel that way > about recursion? I feel that this has to do with the history of mathematics (you can "derive all of arithmetic" from set theory), and the development of computer science theories as "mathematical in character" with issues related to machine finiteness being left as an afterthought rather than being incorporated into those theories. > 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? Optimizing tail calls. > 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). I am half-disputing this. I feel that TCO has hidden perils lurking in its potentially complex depths. Try it this way: How would you (mechanically) describe J sentences which are valid targets of TCO? (And, phase 2: how would you implement this mechanism in J, given the atomic representations of the sentences in question.) -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
