If you have implemented  libAdvb properly (which is what the message
you were responding to should explain), then a locative reference to
it is all you need to implement libAdvbInSomeLib

Does this make sense?

If not, let's try again with actual meaningful definitions and test cases.

Thanks,

-- 
Raul



On Fri, Mar 31, 2017 at 1:05 PM, Xiao-Yong Jin <jinxiaoy...@gmail.com> wrote:
> I don't see how this would help.  In concrete terms, I want the following
> public stable interface of a library SomeLib,
>
>    cocurrent'SomeLib'
>    libAdvb=:1 :'...'
>    libVerb=:3 :'...'
>
> they refer to each other and a list of other names in SomeLib that should
> remain isolated as hidden implementation details that could change later.
> Now in a separate application,
>
>    cocurrent'SomeApp'
>    appVerb=:3 :0
> ...
> libVerb_SomeLib_ appNoun                        NB. This is OK.
> otherAppVerb libAdvbInSomeLib otherAppNoun      NB. ???
> ...
> )
>
> How would I write libAdvbInSomeLib to actually use libAdvb_SomeLib_, which
> can depend on all the names defined in SomeLib?
>
> The wiki link Henry sent told me to define a new verb in SomeLib, but that
> is undesirable.  The newVerb_SomeLib_ defined in SomeApp pollutes the
> namespace in SomeLib and could clash with existing names.  I wouldn't want
> SomeApp to touch the namespace of SomeLib.
>
> The following seems to work, but I wish for a simpler solution.
>
>    h_t_=:1 : 0          NB. the helper for a_t_
> echo'h_t_ in ',>coname''
> ff_t_=.u a_t_           NB. ff_t_ actually becomes public in t
> ff_t_ y
> )
>    a_t_=:1 : 0          NB. can be a lot more involved definition
> echo 'a_t_ in ',>coname''
> u f y
> )
>    f_t_=:3 : 0          NB. some verb in t
> echo 'f_t_ in ',>coname''
> y
> )
>    f=:3 : 0             NB. some verb outside of t
> echo'f in ',>coname''
> y
> )
>    a=:3
>    f_base_ h_t_ a       NB. need to fully qualify the locale of f, but not a
> aa_t_ in base
> a_t_ in t
> f_t_ in t
> f in base
> 3
>    f h_t_ a             NB. otherwise f_t_ is actually used
> aa_t_ in base
> a_t_ in t
> f_t_ in t
> f_t_ in t
> 3
>    ff h_t_ a            NB. STACK ERROR for fun
>
>
>> On Mar 31, 2017, at 10:39 AM, Raul Miller <rauldmil...@gmail.com> wrote:
>>
>> There are certainly ways to work around this issue. It's just a minor
>> matter of coding them up.
>>
>> The important thing here is that adverb evaluation and verb evaluation
>> are two different things, and when your adverb is named in a locale
>> you need to capture the identity of that locale before creating the
>> verb if you want the verb to execute within that locale.
>>
>> Here's an approach that might work for you:
>>
>> advA_example_=:1 :0
>>  locale=. coname''
>>  u helperA locale
>> )
>>
>> helperA_example_=:2 :0
>>  u__v y
>> )
>>
>> Note also that if you don't like having a named helper, and if it's
>> small enough, you could put it in line:
>>
>> advB_example_=:1 :0
>>  locale=. coname''
>>  u 2 :'u__v y' locale
>> )
>>
>> I haven't actually tested this, but I think I got this right - but let
>> me know if it doesn't work for you.
>>
>> Thanks,
>>
>> --
>> Raul
>>
>>
>> On Fri, Mar 31, 2017 at 11:15 AM, Xiao-Yong Jin <jinxiaoy...@gmail.com> 
>> wrote:
>>> This is less useful.  The simplest case that I use locale for is writing
>>>   a_z_=:a_t_
>>> with a_t_ an explicit definition that uses all the things defined in locale 
>>> 't'.
>>> I could do it, had 'a' been a verb.
>>> With 'a' an adverb or conjunction, I have to suffix all names in 'a_t_' 
>>> with '_t_',
>>> and as you mentioned this is less desirable as I can't override those 
>>> definitions with
>>> the locale path any more.
>>>
>>> Is there any other way to work around it?
>>>
>>> I guess I can always do
>>>   coinsert't'
>>> but that leaves open the possibility of name collisions and removes 
>>> benefits of locales.
>>>
>>>> On Mar 31, 2017, at 8:40 AM, 'Pascal Jasmin' via Programming 
>>>> <programm...@jsoftware.com> wrote:
>>>>
>>>> "The rule" is that "Semi tacit" modifiers can implicitly access members of 
>>>> their own locale.  Explicit modifiers cannot.  The reason why.
>>>>
>>>> +: 1 : 'u'  NB. semi tacit: processes entirely in locale and returns tacit 
>>>> expression (then vanishes)
>>>>
>>>> +:
>>>>
>>>> +: 1 : ' u y' NB. explicit. returns bound explicit expression that 
>>>> executes in some unknown locale.
>>>> +: (1 : ' u y')
>>>>
>>>>
>>>> You can also explicitly label the locales used in an explicit modifier.
>>>>
>>>> 1 : ' u aa_t_ y'
>>>>
>>>> will work from any locale.  Though may not be appropriate when you make 
>>>> "object instances" and need to have the reference move with the instance.
>>>>
>>>>
>>>>
>>>>
>>>> ________________________________
>>>> From: roger stokes <rogerstokes...@gmail.com>
>>>> To: programm...@jsoftware.com
>>>> Sent: Friday, March 31, 2017 4:37 AM
>>>> Subject: Re: [Jprogramming] locales with adverbs and conjunctions?
>>>>
>>>>
>>>>
>>>> If you want  +: a_t_ 3  to give a result of 6 then you need to write:
>>>>
>>>>  a_t_ =: 1 : 'u aa'
>>>>  aa_t_ =: 1 : 'u'
>>>>
>>>>  +: a_t_ 3
>>>> 6
>>>>
>>>>
>>>> On Fri, Mar 31, 2017 at 5:08 AM, Xiao-Yong Jin <jinxiaoy...@gmail.com>
>>>> wrote:
>>>>
>>>>> Does locale change only happens with verbs?
>>>>>
>>>>>  v_t_=:3 :'vv y'
>>>>>  vv_t_=:3 :'+: y'
>>>>>  v_t_ 3
>>>>> 6
>>>>>  a_t_=:1 :'u aa y'
>>>>>  aa_t_=:1 :'u y'
>>>>>  +: a_t_ 3
>>>>> |value error: aa
>>>>> |   u     aa y
>>>>>  c_t_=:2 :'u cc v y'
>>>>>  cc_t_=:2 :'u v y'
>>>>>  +: c_t_ *: 3
>>>>> |value error: cc
>>>>> |   u     cc v y
>>>>>
>>>>> This seems to be very inconvenient.
>>>>> ----------------------------------------------------------------------
>>>>> 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

Reply via email to