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

Reply via email to