t3 is not empty,
   t3
3 : 'NB.'

It seems my assumption that explicit verb being initialized to
i.0 0 is incorrect, but

t5=: 3 : 0
99
if. 0 do. '' end.
)

   t5''
99
 
This is expected, but from where does t4 get the i.0 0 ?

Ср, 01 июн 2016, jprogramming написал(а):
>  3 : ''
> 3 : ''
> 
> 
> could be an error at definition?  t1 to t3 are all equivalent to that.
> 
> Though t4 doesn't execute anything, it is not the same error.
> 
> a reasonable alternative would be:
> 
> (i.0 0)-: 3 : '' a:
> 1
> 
> 
> (i.0 0)-: 3 : 'label_.' 1
> 
> 1
> 
> ----- Original Message -----
> From: bill lam <[email protected]>
> To: [email protected]
> Sent: Tuesday, May 31, 2016 10:16 PM
> Subject: Re: [Jprogramming] Bring out yer bugs
> 
> IIUC, result of explicit verb is initialized to i.0 0
> 
> but t1 t2 t3 all raise domain error. 
> furthermore t4 is ok and 
>    (i.0 0)-: t4''
> 1
> 
> Any theory?
> 
> t1=: 3 : 0
> )
> 
> t2=: 3 : 0
> 
> )
> 
> t3=: 3 : 0
> NB.
> )
> 
> t4=: 3 : 0
> if. 0 do. '' end.
> )
> 
> Вт, 31 май 2016, Henry Rich написал(а):
> > 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
> 
> -- 
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
> 
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to