mybasename adv_loc1_ adv_loc2_
is equivalent to (mybasename adv_loc1_) adv_loc2_ the call to adv_loc2_ is from "base". > Perhaps this other adverb would have been defined in the z locale. This is usually a good idea to avoid most unintended locale issues. It avoids all of the issues in my post. When you define an adverb in z: that adverb will execute in the caller's locale. (if they include 'z' in path which all locales do by default) any definitions in that locale will supercede those that also exist in z you never have to worry your pretty little head about any "flakeyness"/misunderstandings/momentary lapses of portions of universe of consequences from calling foreign locale functions. But, using coinsert 'speciallocale' has the same benefit of peace of mind for user of 'speciallocale', and like 'z', is an extremely useful framework for adding functionality to your application. Saving the long function names with underscores is very user friendly. In my kv locale, using kv as prefix to function names makes it clear what locale they are comming from, and avoids conflicts with names in user locale, unless the user wants them. On Saturday, February 19, 2022, 12:31:50 p.m. EST, Raul Miller <[email protected]> wrote: On Sat, Feb 19, 2022 at 12:16 PM 'Pascal Jasmin' via Beta <[email protected]> wrote: > the caller's locale is the current locale when you call an locatived > expression ie adv_otherlocale_ What would "caller's locale" mean for u. in another adverb defined in another locale, when my locatived expression calls that adverb with u. as its argument, but without a locative name for that other adverb? (Perhaps this other adverb would have been defined in the z locale.) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
