[Jprogramming] 'noun result was required' WAS: Bring out yer bugs
Henry Rich
henryhrich at gmail.com
Thu Jun 2 12:18:41 UTC 2016
I have changed the explicit-definition code (cx.c) to give the following
results:
f =: 3 : 0 NB. last B sentence is not last sentence executed
r =. y + 5
y + undefname
if. 0: y -: 6 do.
r =. r + 1
end.
)
f 5
|noun result was required: f
| y+undefname
g =: 3 : 0 NB. last B sentence is last sentence executed
y + undefname
)
g 5
|noun result was required: g
| y+undefname
h =: 3 : 0 NB. T block producing non-noun
r =. y + 1
if. y + undefname do.
r =. r + 1
end.
y
)
h 5
|noun result was required: h
| y+undefname
j =: 3 : 0 NB. T-block error in try., caught
r =. y + 1
try.
if. y + undefname do.
r =. r + 1
end.
catch.
y =. 'caught!'
end.
y
)
j 5
caught!
In all cases, when there is an error the debugger points to the same
line that was shown in the error message (which may not be the last line
that was executed).
AFAICS this responds to all the suggestions.
Henry Rich
On 5/31/2016 10:40 PM, bill lam wrote:
> t3 is not empty,
> t3
> 3 : 'NB.'
>
> It seems my assumption that explicit verb being initialized to
> i.0 0 is incorrect, but
>
> t5=: 3 : 0
> 99
> if. 0 do. '' end.
> )
>
> t5''
> 99
>
> This is expected, but from where does t4 get the i.0 0 ?
>
> Ср, 01 июн 2016, jprogramming написал(а):
>> 3 : ''
>> 3 : ''
>>
>>
>> could be an error at definition? t1 to t3 are all equivalent to that.
>>
>> Though t4 doesn't execute anything, it is not the same error.
>>
>> a reasonable alternative would be:
>>
>> (i.0 0)-: 3 : '' a:
>> 1
>>
>>
>> (i.0 0)-: 3 : 'label_.' 1
>>
>> 1
>>
>> ----- Original Message -----
>> From: bill lam <bbill.lam at gmail.com>
>> To: programming at jsoftware.com
>> Sent: Tuesday, May 31, 2016 10:16 PM
>> Subject: Re: [Jprogramming] Bring out yer bugs
>>
>> 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" <henryhrich at gmail.com> 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
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
More information about the Programming
mailing list