> This is a 'feature' of J that many (including me) have considered a bug. If >enough argument can be marshaled to carry that point, it could be changed.
I would be weary of changing it, but u. could be enhanced. a_utilities_ =: 1 : 'u % count_utilities_' b_utilities_ =: 1 : 'u. % count_utilities_' sum_base_ =: +/ sum_utilities_ =: [: count_utilities_ =: # currently u. only "works" inside a private namespace of an explicit definition. (calling from base in following) sum b_utilities_ 1 2 3 0.333333 sum a_utilities_ 1 2 3 0.333333 sum f. a_utilities_ 1 2 3 2 The 1st and last expressions should match, where in the b. adverb u. should prefer dereferencing name from the caller's locale ahead of its own, though the last expression is the workaround. This seems to match u.'s purpose of interacting with caller's environment. new AVV trains do "work" c_utilities_ =: (@]) % count_utilities_ sum c_utilities_ 1 2 3 2 hmmm... just sometimes d_utilities_ =: ]: % count_utilities_ sum d_utilities_ 1 2 3 0.333333 On Friday, February 18, 2022, 11:24:58 p.m. EST, Henry Rich <[email protected]> wrote: Your idea for checksumming entities might have merit. The AC() field of a block - the usecount - is subject to change, but the rest of a block should be immutable after assignment. Moving on to the immediate problem you cite, I point out that there is no such thing as a 'locale-specific verb'. A verb is defined by its text. What locale it executes in is given entirely by the rules for changing the implied locale given at https://code.jsoftware.com/wiki/Vocabulary/Locales#Changing_the_implied_locale . Usually you get the effect of a locale-specific verb by executing verbname_specificlocale_ . The JE code implementing this follows the spec closely and I would be surprised if it got confused. If you were executing a modifier referring to x or y, remember that no matter what locale the modifier was executed in, the derived verb is not a locative and does not change the current locale. This is a 'feature' of J that many (including me) have considered a bug. If enough argument can be marshaled to carry that point, it could be changed. hhr On 2/18/2022 7:54 PM, Raul Miller wrote: > I ran into an issue today, where locale specific verbs were running in > base rather than in the locale where they were defined (j903). > > Exiting and restarting J fixed the problem. At least for now. > > But I am now wondering about the viability of some kind of "integrity > dump" where J somehow exposes something about supposed internal > constants -- perhaps a checksum of the "constants" defined at startup? > > Being able to detect when things have gone awry should help. (I do not > know if the problem was caused by a flaw in J, in the operating system > or in the hardware, or in whatever else. But having test mechanisms > might shed clues...) > > Thanks, > -- This email has been checked for viruses by AVG. https://www.avg.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
