IIUC, result of explicit verb is initialized to i.0 0 but t1 t2 t3 all raise domain error. furthermore t4 is ok and (i.0 0)-: t4'' 1
Any theory? t1=: 3 : 0 ) t2=: 3 : 0 ) t3=: 3 : 0 NB. ) t4=: 3 : 0 if. 0 do. '' end. ) Вт, 31 май 2016, Henry Rich написал(а): > Well, that's a design question. The problem is, the JE doesn't know that > the sentence (5 + undefname) causes a problem until the end of the > definition is reached. By that time, many sentences (in T blocks) may have > been executed. There are two issues that I see: > > 1. What should the debugger do? Should it stop on the (5 + undefname) line, > as if that line had just failed on its own? That would be the most > informative thing to do UNLESS the sentences executed later have changed the > program state so much that it's hard to make sense of the (5 + undefname) > line. > > 2. If debug is off, what should be reported? Here, I have no doubt that the > best solution would be a 'non-noun result' on the (5 + undefname) line. > > Let us agree that in case 2 I will give a 'non-noun result' showing the line > causing the problem. That will handle most of the real-life situations > where this would come up. > > What about case 1? Should: > > 1. the debugger stop on the line which is not the last one executed; > 2. the debugger stop after the execution of the verb, as it does now (with a > syntax error); > 3. like case 1, but with some indication in the stack that this weird > situation has occurred > > Henry Rich > > > > On 5/31/2016 6:29 PM, bill lam wrote: > > Ok, it sounds reasonable.But you said, > > > > " > > + undefname > > if. 0 do. end. > > ) > > > > would not be caught" > > > > Shouldn't it also be a "non-noun result" error? > > On Jun 1, 2016 3:13 AM, "Henry Rich" <[email protected]> wrote: > > > > > I agree with your analysis but not your conclusion. > > > > > > f =: 3 : 0 > > > 5 + y > > > 111 + yy > > > ) > > > > > > In the current system we have > > > > > > f 5 > > > > > > |syntax error: f > > > > > > | f 5 > > > > > > Wouldn't we be happier with > > > > > > f 5 > > > |non-noun result: f > > > |111 + yy > > > > > > > > > In my J classes, this is the one error where I just have to find it for > > > the students rather than explain it to them. > > > > > > > > > I am suggesting this definition: a sentence that completes normally, but > > > is in a context where a noun result is required (as the last sentence in a > > > T-block or the last sentence before return. or end-of-definition), is > > > flagged with the 'non-noun result' error if it does not produce a noun. > > > > > > > > > Wouldn't that be better? > > > > > > > > > This would include both errors in > > > > > > > > > f =: 3 : 0 > > > if. test y do. > > > + > > > else. > > > - > > > end. > > > ) > > > > > > > > > Henry Rich > > > > > > > > > > > > > > > On 5/31/2016 12:16 PM, bill lam wrote: > > > > > > > IMO the sentence > > > > 5 + undefname > > > > itself is not an error. The error is the verb v returning it as > > > > a result. So I prefer leave it as is (both not caught inside v). > > > > > > > > Similar argument would also hold for B block, but since it is > > > > difficult to debug, so that changing it will make us happier. > > > > > > > > > > > > Вт, 31 май 2016, Henry Rich написал(а): > > > > > > > > > Unquestionably, sentences producing non-noun are OK as long as they > > > > > don't > > > > > end a T-block or a verb. > > > > > > > > > > What I was proposing in (b) was that > > > > > > > > > > v =: 3 : 0 > > > > > ... > > > > > 5 + undefname > > > > > ) > > > > > > > > > > would be caught before exiting the verb, so that in debug you would > > > > > point to > > > > > the bad sentence rather than the calling verb. > > > > > > > > > > In contrast, > > > > > > > > > > > > > > > v =: 3 : 0 > > > > > ... > > > > > 5 + undefname > > > > > if. 0 do. end. > > > > > ) > > > > > > > > > > would not be caught. > > > > > > > > > > Henry Rich > > > > > > > > > > > > > > > On 5/31/2016 11:38 AM, bill lam wrote: > > > > > > > > > > > As the current behavior permit non-noun as the execution result > > > > > > of a sentence in an explicit verb definition, so I prefer leave > > > > > > as is (for B block). > > > > > > > > > > > > It the verb returns a non-noun, it will raise a syntax error > > > > > > in current J behavior although "non-noun result" error message > > > > > > would be easier to be understood by new comers. > > > > > > > > > > > > In contrast, the context of T block expected a noun, I prefer it > > > > > > to be caught at the crime scene. > > > > > > > > > > > > Just for clarification, non-noun result in the middle of T block > > > > > > is fine. > > > > > > > > > > > > t1=: 3 : 0 > > > > > > if. > > > > > > 1 > > > > > > + > > > > > > 2 > > > > > > do. 3 else. 4 end. > > > > > > ) > > > > > > > > > > > > Вт, 31 май 2016, Henry Rich написал(а): > > > > > > > > > > > > > There are two different problems to consider. > > > > > > > > > > > > > > 1. A non-noun result at the end of a T block should be detected > > > > > > > as an > > > > > > > error > > > > > > > on the do., and should trap or go to catch. like any other error. > > > > > > > Both of > > > > > > > your examples come under this heading. I will fix this. > > > > > > > > > > > > > > 2. A non-noun result at the end of a B block is different, because > > > > > > > there > > > > > > > more sentences may be executed: > > > > > > > > > > > > > > if. 1 do. > > > > > > > + > > > > > > > end. > > > > > > > if. 0: SomeComplicatedVerb y do. > > > > > > > 5 > > > > > > > end. > > > > > > > return. > > > > > > > > > > > > > > The + is going to cause an error, but not until after the later T > > > > > > > block, > > > > > > > including SomeComplicatedVerb, has been executed. > > > > > > > > > > > > > > I can think of solutions: > > > > > > > a. leave as is > > > > > > > b. if the non-noun sentence is the last sentence executed before > > > > > > > leaving the > > > > > > > verb, trap on it; otherwise continue as now > > > > > > > c. always go back and trap on the non-noun sentence when it is > > > > > > > discovered > > > > > > > that it is generating the erroneous return value, even though > > > > > > > other > > > > > > > later > > > > > > > sentences may have executed and completely changed the program > > > > > > > state > > > > > > > > > > > > > > What solution is best? > > > > > > > > > > > > > > Henry > > > > > > > > > > > > > > On 5/28/2016 10:23 AM, bill lam wrote: > > > > > > > > > > > > > > > Sorry I had not included an example, it is about debug > > > > > > > > suspension stack. > > > > > > > > > > > > > > > > t1=: 3 : 0 > > > > > > > > 1 > > > > > > > > t2'' > > > > > > > > 4 > > > > > > > > ) > > > > > > > > > > > > > > > > t2=: 3 : 0 > > > > > > > > 1 > > > > > > > > 2 > > > > > > > > 3 > > > > > > > > if. 0-: notexist_base_ do. end. > > > > > > > > 4 > > > > > > > > 5 > > > > > > > > 6 > > > > > > > > ) > > > > > > > > > > > > > > > > dbr 1 > > > > > > > > t1'' > > > > > > > > |control error: t2 > > > > > > > > |t2[3] > > > > > > > > > > > > > > > > NB. this seemed ok, but > > > > > > > > > > > > > > > > dbstack'' > > > > > > > > +----+--+--+--+----+------+----+ > > > > > > > > |name|en|ln|nc|args|locals|susp| > > > > > > > > +----+--+--+--+----+------+----+ > > > > > > > > |t1 |23|1 |3 |++ |+-++ |* | > > > > > > > > | | | | ||| ||y|| | | > > > > > > > > | | | | |++ |+-++ | | > > > > > > > > +----+--+--+--+----+------+----+ > > > > > > > > dbctx'' > > > > > > > > @@ t1[1] *v @@ /home/bill/a1.ijs > > > > > > > > 3 : 0 > > > > > > > > [0] 1 > > > > > > > > > > > > > > > > > [1] t2'' > > > > > > > > > > > > > > > > > [2] 4 > > > > > > > > > > > > > > > > NB. the top of stack (13!:13) is not t2. > > > > > > > > > > > > > > > > Сб, 28 май 2016, Henry Rich написал(а): > > > > > > > > > > > > > > > > > I can reproduce the problem, which seems to be that a T block > > > > > > > > > that > > > > > > > > > has a > > > > > > > > > non-noun result doesn't go to the catch. > > > > > > > > > > > > > > > > > > I don't understand your second part: > > > > > > > > > > > > > > > > > > Also control error will can only be reported after exiting the > > > > > > > > > explicit verb, not the lines of control block. > > > > > > > > > > > > > > > > > > Can you give an example of that? > > > > > > > > > > > > > > > > > > I will work on this right after we get all the current > > > > > > > > > branches > > > > > > > > > merged together. > > > > > > > > > > > > > > > > > > Henry Rich > > > > > > > > > > > > > > > > > > > > > > > > > > > On 5/27/2016 9:32 PM, bill lam wrote: > > > > > > > > > > > > > > > > > > > The handling of control error I had report many years ago, > > > > > > > > > > > > > > > > > > > > http://www.jsoftware.com/pipermail/beta/2006-August/001776.html > > > > > > > > > > > > > > > > > > > > Also control error will can only be reported after exiting > > > > > > > > > > the > > > > > > > > > > explicit verb, not the lines of control block. > > > > > > > > > > > > > > > > > > > > But Roger said it was the intended behavior. Can you take > > > > > > > > > > a look? > > > > > > > > > > > > > > > > > > > > Вт, 17 май 2016, Henry Rich написал(а): > > > > > > > > > > > > > > > > > > > > > The J Engine is being worked on again. The people > > > > > > > > > > > working on it > > > > > > > > > > > are not > > > > > > > > > > > experts on it yet, but we have fixed quite a few of the > > > > > > > > > > > long-standing bugs > > > > > > > > > > > and have plans for improvements. > > > > > > > > > > > > > > > > > > > > > > There have long been Wiki pages for reporting bugs, > > > > > > > > > > > pointed to by > > > > > > > > > > > > > > > > > > > > > > http://code.jsoftware.com/wiki/System/Interpreter/Bugs > > > > > > > > > > > > > > > > > > > > > > especially > > > > > > > > > > > > > > > > > > > > > > http://code.jsoftware.com/wiki/System/Interpreter/Bugs/Crashes > > > > > > > > > > > and > > > > > > > > > > > http://code.jsoftware.com/wiki/System/Interpreter/Bugs/Errors > > > > > > > > > > > > > > > > > > > > > > Quite a few of these have been fixed. If you have other > > > > > > > > > > > bugs that > > > > > > > > > > > are not > > > > > > > > > > > listed on those pages, please add an entry for them! The > > > > > > > > > > > recent > > > > > > > > > > > report of > > > > > > > > > > > trouble with > > > > > > > > > > > > > > > > > > > > > > +.~1 2 1j_. 3 > > > > > > > > > > > > > > > > > > > > > > would be a model candidate. > > > > > > > > > > > > > > > > > > > > > > Add an entry for your problem, and it'll get fixed. > > > > > > > > > > > > > > > > > > > > > > Henry Rich > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > 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 > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > 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 > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm -- regards, ==================================================== GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
