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
