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
