Sorry Typo, I meant hold for T block. Ср, 01 июн 2016, bill lam написал(а): > 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 > > -- > regards, > ==================================================== > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
-- 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
