I think you also need to test for locked scripts where f. is an
no-op for explicit definitions.

Вт, 31 май 2016, jprogramming написал(а):
> Not sure if this is a bug, but its definitely weird.
> 
> + 1 : 'if. 1 do. a =.u end. a f.'
> +
> + 1 : 'if. 1 do. a =.u end. a '  NB. returns value of caller locale's 'a'~
> ;:'+-'
> 
> 
> Its an easy work around to use f. to return internal variables from adverbs, 
> but it would not be universe imploding if you wished to return a 
> global/caller localed variable to refrain from the unintuitive shaddowing of 
> it within your explicit expression.
> 
> My suggestion would be that the 2nd expression is always equivalent to first.
> 
> 
> 
> A_test_ =: 1 : 'if. 1 do. a =.u end.a'
> a_test_ =. *
> 
> + A_test_
> ;:'+-'
> 
> + 1 : 'if. 1 do. a =.u end. u a (a f.)' 
> + a +
> 
> The argument against this involves allowing duck typing to caller's locale 
> which can still be accomplished by avoiding shaddowing the duck typed 
> variable either as a local or (adverb) locale definition.
> 
> 
> ----- Original Message -----
> From: Henry Rich <[email protected]>
> To: [email protected]
> Sent: Tuesday, May 31, 2016 10:58 AM
> Subject: Re: [Jprogramming] Bring out yer bugs
> 
> 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

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