Since the current behavior matches the documentation and is more
flexible that the suggested behavior, I would vote to leave things as
is. Users sophisticated enough to write modifiers can deal with the
name-resolution rules.
Henry Rich
On 5/31/2016 11:42 AM, 'Pascal Jasmin' via Programming wrote:
Not sure if this is a bug, but its definitely weird.
+ 1 : 'if. 1 do. a =.u end. a f.'
+
+ 1 : 'if. 1 do. a =.u end. a ' NB. returns value of caller locale's 'a'~
;:'+-'
Its an easy work around to use f. to return internal variables from adverbs,
but it would not be universe imploding if you wished to return a global/caller
localed variable to refrain from the unintuitive shaddowing of it within your
explicit expression.
My suggestion would be that the 2nd expression is always equivalent to first.
A_test_ =: 1 : 'if. 1 do. a =.u end.a'
a_test_ =. *
+ A_test_
;:'+-'
+ 1 : 'if. 1 do. a =.u end. u a (a f.)'
+ a +
The argument against this involves allowing duck typing to caller's locale
which can still be accomplished by avoiding shaddowing the duck typed variable
either as a local or (adverb) locale definition.
----- Original Message -----
From: Henry Rich <[email protected]>
To: [email protected]
Sent: Tuesday, May 31, 2016 10:58 AM
Subject: Re: [Jprogramming] Bring out yer bugs
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
