> This probably does what you "really want", and in > this > case the results of the above would be > 5 > 8 > 11
Actually, what I'd really want is 5 5 5 You're right, the most logical implementation involves caching the last result(s). Caching only a single result would provide 99%+ of the usefulness, and minimize the length of time data need held in memory cached, but in a world where 1GB of RAM is common, extended caching could be well within resources of many. I'd assume the last result is already cached, since it is needed for return values, in which case, ignore my 3rd paragraph here. Another benefit of caching the result rather than providing a shorthand for inserting the last expression at the cursor is whenever the intermediate results take less than instant computation time. It would let you keep your sanity checks without recalculating everything. Another possible implementation is as yet another potential plugin into a preprocessor engine. There is a straightforward code substitution equivalent from the multiline version to a single line version, that can be used when not in debug mode. Because the intermediate values are never the last line in a script, they can be optimized away (theoretically). --- "Miller, Raul D" <[EMAIL PROTECTED]> wrote: > Pascal Jasmin wrote: > Sent: Wednesday, September 13, 2006 10:54 AM > > languages (Forth). I'm not particularly familiar > with > > these, but if a monad solution is adopted, > > [. 1 -- previous evaluation > > [. 2 -- line before that > > [. 1 2 -- boxed pair of last 2 evaluations? > > [. 0 -- some kind of self reference, i'm unsure is > > needed... and if not, could refer to previous > line, > > and simplify the simplest multiresult uses. > > This would seem to lead to a variety of subtle bugs. > > For example, different people should have > different intuitions about what the following > would produce: > a=:2 > f=: 'a=:a+y' > f 3 > [. 1 > [. 1 > > One approach is "previous evaluation" means that > J stores the result of each line it executes. This > would rapidly lead to out of memory conditions for > people working with large data sets. > > Another approach is that "previous evaluation" means > that the previous expression is recorded and > executed. > The obvious implementation of this results in a > stack > full error for the second [. 1 > > Another approach would be to special case recursion > on [., where the offset is adjusted in each > recursion. > This probably does what you "really want", and in > this > case the results of the above would be > 5 > 8 > 11 > > However, this becomes hard to understand, and does > not result in the creation of a re-usable > expression. > > In my experience, when I've got several screens of > evaluations going, I sometimes have introduced an > error > and I have to go back and do things over again to > see > where I've gone wrong. This does not happen for > simple > cases but does happen for complex cases. I don't > see > how I could accomplish this if my session was > littered > with [. n expressions. The only times you [. would > produce something re-usable are the cases where it's > not doing anything useful. > > As an aside, it seems like it should be possible to > find the function which handles ctrl shift uparrow, > and bind it to another key, but I have not been > able to find it. > > -- > Raul > > ---------------------------------------------------------------------- > For information about J forums see > http://www.jsoftware.com/forums.htm > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
