p.s. you can claim that you know J very well. ;)
Thanks, -- Raul On Mon, Aug 25, 2014 at 8:35 PM, Jose Mario Quintana <[email protected]> wrote: > Pascal wrote: > " > use of terms like "recursion with tail call optimization" come from lisp > fold implementations where in order to avoid stack growth/exhaustion (/ > avoids such stack abuse btw), you need to pass any accumulator (state > between function calls) as a parameter to the function. boxscan basically > allows the anything lisp can do, can be done with boxscan (and each/ at its > core) thinking. > " > > This sounds very interesting. There is a technique, trampolining, that > supposedly allows for an implementation of tail call optimization; see for > example > http://weblambdazero.blogspot.com/2010/07/advanced-recursion-in-newlisp.html > for an implementation in NewLISP and > http://www.integralist.co.uk/posts/understanding-recursion-in-functional-javascript-programming/ > for an implementation in JavaScript. As far as I can see, this trampoline > is a tool (function) written in a target language that allows for TCO > without the need to alter the interpreter. Glancing at these articles > references to accumulators and passing arguments pop up. > > Can you really write an equivalent trampoline verb or adverb in J using > boxscan (or anything else)? Further, can you write a wrapper adverb to > modify a recursive verb to optimize it via the trampoline? I would love to > see such tools in a familiar language (explicit versions would be welcome). > Please be gentle with you answer; I am not a computer scientist; I know > next to nothing about LISP, NewLISP or JavaScript; I cannot not even claim > that I know J very well. > > > On Mon, Aug 25, 2014 at 2:40 PM, 'Pascal Jasmin' via Programming < > [email protected]> wrote: > >> / and boxscan are indeed fold and reduce in other languages. The lisp >> implementations probably the easiest to understand. >> >> The big difference between / and boxscan is that / applied to a list >> implies a requirement that all items in the list are the same shape. >> boxscan can use any list of arguments as the x, and appends any shape as >> the y, as long x u y results in a shape "compatible with y" (more >> accurately compatible with future applications of x u result . >> >> use of terms like "recursion with tail call optimization" come from lisp >> fold implementations where in order to avoid stack growth/exhaustion (/ >> avoids such stack abuse btw), you need to pass any accumulator (state >> between function calls) as a parameter to the function. boxscan basically >> allows the anything lisp can do, can be done with boxscan (and each/ at its >> core) thinking. >> >> A neat feature regarding tacit adverbs in general, is that I can type >> boxscan in source code, but the actual definition will be "compiled away" >> as if it were called with f. . using the term boxscan can help with >> readability if the intent of the function is to create a rightmost >> accumulator state. >> >> >> >> >> ----- Original Message ----- >> From: Raul Miller <[email protected]> >> To: Programming forum <[email protected]> >> Cc: >> Sent: Monday, August 25, 2014 1:16:58 PM >> Subject: Re: [Jprogramming] Adler-32 >> >> I have a nitpick with your phrasing here. >> >> Instead of saying "... use / recursively... (tail call optimization)" >> I think you should say something else. >> >> Mind you, I'm not quite sure what you should say. >> >> And, it's a nice clever bit of code. And here's another example of how >> I might use the concept of "use" - I am using the usual J convention >> where we indent the expression but not the result: >> >> (long sentence here) ((&.>)/)(>@:) >> >@:((long sentence here)&.>/) >> >> But I can't quite bring myself to say that this is "using / recursively". >> >> I think I recognize the thought process - the argument to boxscan is a >> binary operator or what we call a dyadic verb, and the underlying >> concept here (which might be called "reduce", "insert" or "fold") is >> often implemented recursively in other contexts. >> >> But / itself represents that same operation. So it's the >> implementation of / or the concept of / which would attach to the >> concept of "recursively", but that's something very different, in my >> mind, from "using / recursively". >> >> Using / recursively seems like it ought to repeatedly use / in the >> same context (instead of just once). >> >> Maybe the sentence should have been "make the use of / more closely >> match a tail call recursive list scan"? >> >> I'm not sure. >> >> (Should I take this kind of side thought to the chat forum?) >> >> Thanks, >> >> -- >> Raul >> >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
