Thanks for the feedback. In windows, Ctrl-shift-Up brings up the last line. I believe Ctrl-Up will scroll. I would certainly vote to swap the functionality of those hotkeys, and it would fit better with general console conventions.
I agree with all of your suggested improvements. I will reiterate benefits a bit. A very natural way to learn to write J sentences is to keep trying to extend them on the left, after intermediate testing. So this is a solution to the oppressive burden of ctrl-shift-up-home. while I admit to maintainability issues, In the line debugger, having easier access to intermediate values would give better information compared to long sentences. It would not be any less maintainable than the single line equivalent. Another, simpler option, is to limit it to only a single previous expression, and so behave like the nilladic $: as you said... --- "Mark D. Niemiec" <[EMAIL PROTECTED]> wrote: > 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 > __________________________________________________ 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
