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

-- 
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