13!:1 is unpredictable if debug is off. I know much less information is
saved, and I think not enough to show the word in error.
In any case 13!:1 should be considered illegal when debug is off, and
thus is not to be relied on to solve the problem we are discussing.
Henry Rich
On 6/2/2016 9:04 AM, Don Guinn wrote:
I'v wondered about that too. I played with example some with interesting
results. It is with debug off, yet 13!:18'' returns a stack, but it doesn't
show any of the tacit stuff.
From help:
13!:1 y *Display Stack*. Only named definitions (verb, adverb, or
conjunction) are put on the stack. See also 13!:13 and 13!:18 .
erase 'xxx'
1
example=:3 :0"1&.>
xxx=:13!:18 ''
'problem'13!:8]9
)
runex=:3 : 0
NB. filler
3+example 4 5
NB. filler
)
1+example 2 3
|problem: example
| 'problem' 13!:8]9
xxx
| 1+ example 2 3
erase 'xxx'
1
1+runex 2 3
|problem: example
| 'problem' 13!:8]9
xxx
| 3+ example 4 5
| 1+ runex 2 3
It looks like xxx, contains the traceback information, some form of stack,
13!:18 got it from somewhere and it is what is needed to show the error as
I requested.
On Thu, Jun 2, 2016 at 6:08 AM, Raul Miller <[email protected]> wrote:
Unless you can defer the signaling of the error to the caller?
The real question and problem would be: what is the "caller"? (This
issue is somewhat similar to the previous discussion about
stop-at-line behavior in the context of derived explicit verbs.) In
other words, what should we get for this?
example=:3 :0"1&.>
'problem'13!:8]9
)
example L:2 <^:(i.5)a:
And that is probably why it behaves as it does:
(<'like this') E every <99
|like this: E
|E[:0]
Perhaps a better solution, then, would be to introduce a companion
foreign (or, better yet, a control word) which behaves something like
a blend between (assert.) and 13!:8. (Perhaps not quite the same,
since assert. was designed to let you disable expensive computations
and be ignored in production code, and of course there's this whole
error message thing.)
I do not know what the best syntax for that would be, here are some
possibilities:
NB. verbose syntax
3 :'error. 9 do. ''like this'' end.'
or
NB. a bit more concise:
3 :'''like this'' error. 9' 0
or
NB. even more concise, but limits text of error messages:
3 :'like this error 9.' 0
If we decide we actually want to do this, and maybe decide on the
syntax (and whether it makes sense to disable this in production code)
it then becomes reasonable to look at wc.c for how we'd fit it in
there.
Thanks,
--
Raul
On Thu, Jun 2, 2016 at 7:32 AM, Henry Rich <[email protected]> wrote:
I have not been able to follow the debug code all the way to the end,
but it
appears to me that the stack doesn't exist except when debugging is
turned
on, & thus it would not be possible to format a message about the line
that
called the line containing 13!:8.
Henry Rich
On 6/1/2016 6:04 PM, Don Guinn wrote:
Sorry about the sloppy message earlier. Things go wrong when hurrying to
get ready to go shopping.
My proposal: That (13!:8), instead of displaying the statement
containing
the signal (13!:8) which is the statement at the top of the stack that
it
display the next statement in the stack, the one using the explicit
definition incorrectly. All else is unchanged.
Here is a simple script to illustrate:
NB.*signal v gives an error message showing the second line in the
stack.
NB. Only for demo purposes of what the message should look like
NB. Not sufficient for practical use.
NB. It displays 1{13!:18'' instead of 0{13!:18''
signal=:3 : 0
NB. Display statement on top of stack followed by system defined
message.
echo ((<:y)((;@{) :: ('Error'"_))9!:8'')
echo 1{13!:18''
13!:0]0
:
NB. Display statement on top of stack followed by user defined message.
echo x
echo 1{13!:18''
13!:0]0
)
f1=:3 : 0
if. 4=3!:0 y
do. >:+:y
else. 'the argument is not an integer'(13!:8)123
end.
)
f2=:3 : 0
if. 4=3!:0 y
do. >:+:y
else. 'the argument is not an integer' signal 123
end.
)
NB. End of script _________________
NB. f1 and f2 perform some calculations for integers, but they give an
error if y is not an integer.
3+f1 1 2 3
6 8 10
3+f2 1 2 3
6 8 10
NB. Both f1 and f2 give no error when y is integer
3+f1 'text'
|the argument is not an integer: f1
| 'the argument is not an integer' (13!:8)123
NB. f1 gives an error message.
NB. The second line shows the statement containing (13!:8) in f1, the
top
of the stack.
3+f2 'text'
the argument is not an integer
| 3+ f2'text'
NB. f2 shows the next line in the stack which shows the statement using
f2
improperly.
NB. Compare this to using the primitive + below.
3+'text'
|domain error
| 3 +'text'
Notice that the error message for f2 looks like the primitive + error
message which is showing the statement that is using f2 improperly or
in a
way that it is not intended.
On Wed, Jun 1, 2016 at 2:34 PM, Henry Rich <[email protected]>
wrote:
You have my suggestion right; don't know about Don's.
Henry Rich
On 6/1/2016 2:32 PM, Raul Miller wrote:
Compare these two error cases:
3 :''0
|domain error
| 3 :''0
3 :'''example''13!:8]9'0
|example
| 'example' 13!:8]9
In the first error, the error message is followed by the line
containing the error.
If I understand your proposal, I think you would have the second
example look like this:
3 :'''example''13!:8]9'0
|example
If I understand Don Guinn's counter proposal, I think the second
example would look like this:
3 :'''example''13!:8]9'0
|example
| 3 :'''example''13!:8]9'0
Let me know if I have misunderstood?
Thanks,
----------------------------------------------------------------------
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
