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
