Pascal Jasmin <[EMAIL PROTECTED]> wrote: > 1. In interactive mode, a very convenient way of > exploring... making sure intermediate results are as > expected. -- if this is the only recognized benefit, > then a console shortcut to paste last expression at > cursor is probably more useful.
It is very easy to recall a recent sentence by typing 'Ctrl+Up', and prefixing it with 'a =:' if you want to save the result (assuming that the expression does not have side-effects). If it DOES have side-effects, you would be wise to always prefix such expressions with useful results with '[ a =:' or something similar. > 2. A readability assist in scripts, where some people > may prefer the organizational chunking of separate > lines or simplify any logical discomforts in the right > to left parsing. Especially in scripts, where you KNOW which results will need to be used later, it is better to assign them to explicit (and hopefully descriptive) names. value =. ... foo ... size =. ... bar ... other =. ... baz ... y =. other f size g value is clearer than v2 =. ... foo ... v1 =. ... bar ... v0 =. ... baz ... y =. v2 f v1 f v0 which, in turn, is clearer than ... foo ... ... bar ... ... baz ... y =. ([.0) f ([.1) g ([.2) and much easier to maintain. If the second line gets too complicated, and you want to split it into two lines, the first two solutions are unchanged, but the last one requires many of the instances of [. to be renumbered. This is as just as bad as APL which did branching by using an integer line-number parameter to the -> goto arrow - if code line numbers were renumbered, you had to manually change all the branch expressions that referred to line numbers beyond that point. > 3. J's attempt to be the 1 language to rule them all > ignores any embracing and extending of stack based > languages (Forth). No language can possibly implement all programming paradigms and do so efficiently. At some point, you have to pick something, and be good at it. > I'm not particularly familiar with > these, but if a monad solution is adopted, It is often unwise to suggest that something you don't know well be changed to implement something else you don't know well :) > [. 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. In the spirit of J, which uses a 0 for index origin, one would expect [.0 to be the most recent, [.1 as the second, [.2 as the third, etc. > 4. It can be used following a control structure to > pick up whatever happened to be the last executed > evaluation... essentially being another control > structure itself. > > +/ % # > ([. 0) 1 3 5 NB. =3... use last evaluation with > parameters Unfotunately, J verbs are restricted to returning nouns, so while a monadic verb [. could do what you want for previous sentences returning nouns, it could not work for verbs or operators. Now, this could be changed by making [. an adverb i.e. 0[. would return the previous expression, 1[. the one before that, etc. I think that the biggest problem with this entire mechanism is that it presupposes a stack architecture which J does not have - whenever a sentence is evaluated, the most recent value is remembered (since it is returned from verbs by return. or by falling off the end), but any previous values are presumably discarded; otherwise, memory would fill up with them. One way to get around this would be to add another 9!: foreign to define a 'remembered stack depth' which would default to 1, but could be set to higher values, and the parameter to [. would have to be less than this. (This could cause performance degradation, keeping around many unnecessary intermediate results). Another way would be to make [. a proxy (like $:) that takes no arguments, but merely refers to "previous expression". (I am also not particularly comortable with the use of the word [. since in J4, [. [: and ]: were primitive operators; I would be much happier with `. ) -- Mark D. Niemiec <[EMAIL PROTECTED]> ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
