Actually this turns out to be consistent with regular definitions.
b =. + a + NB. leaves a "late bound" and b gets updated if a is changed.
b =. + 1 : 'if. 1 do. a =.u end. u a (a f.)'
b
+ a +
a =. *
b 3
9
a =. +
b 3
6
its even consistent with simpler expression if you assign the result of
simplest expression.
b =. + 1 : 'if. 1 do. a =.u end. a '
b
a
2 b 3
5
Its not consistent with nouns. (but regular definitions work the same)
b =. + 1 : 'if. aa =. 1 do. a =.u end. aa a u'
b
1 a +
----- Original Message -----
From: Henry Rich <[email protected]>
To: [email protected]
Sent: Tuesday, May 31, 2016 12:00 PM
Subject: Re: [Jprogramming] Bring out yer bugs
Since the current behavior matches the documentation and is more
flexible that the suggested behavior, I would vote to leave things as
is. Users sophisticated enough to write modifiers can deal with the
name-resolution rules.
Henry Rich
On 5/31/2016 11:42 AM, 'Pascal Jasmin' via Programming wrote:
> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
