Note that, conceptually, at least, your proposed name_.. might not
need full locking of all name lookups.
Such locking is technically only needed when an execution containing
the specific name has been parsed.
So, conceptually speaking, most name lookups would only need a "read
lock" (which can be shared by many readers) except for names marked
under a parse activated "write lock" (which must be unique). Once a
name is marked with a non-zero _.. count that name lookup would need a
unique write lock before its value could be relied on, but if that's
needed for correctness, it would be a worthwhile cost.
When the parse is discarded it would need to decrement any _.. counts it had.
Note that this would mean that shadow names would need to be retained
even after a name was erased, so erase (and assignment and the copath
mechanism) would also need some additional locking logic which is
cognizant of the copath of the namespace which has those shadow names
(pushing the lock count down the path if a more global name exists,
subtracting the lock count when the shadow is no longer cast).
In principle those read locks might be negligible but that's an
uninformed judgement on my part. I don't actually know how slow they
would wind up being...
Elijah, Henry: Does this sound like a plausible mechanism to you?
Thanks,
--
Raul
On Wed, Jan 18, 2023 at 10:50 AM Henry Rich <henryhr...@gmail.com> wrote:
>
> You are addressing a need, I admit, but one that is fairly rare, and the
> proposed change is drastic IMO. The need is for something like lexical
> scope, when function g can refer to a local name in function f.
>
> Rather than remembering the environment, suppose we added some syntax if
> g to indicate references into f? Some decorated g, say name_., would
> mean 'name when g was defined' and would be replaced in the definition
> of g by its current value in f (or higher). Some other decorated g, say
> name_.., would mean 'name as found in f when name_.. is stacked'.
>
> I would vote against having name_.. because it would slow down name
> lookup. Currently, lookups of private names do not require locking the
> name table, since there can be no other lookup into it. That would be lost.
>
> name_. OTOH seems like a welcome addition. Unfortunately I have much
> more often wanted name_.. .
>
> Henry Rich
>
> On 1/17/2023 10:58 PM, Elijah Stone wrote:
> > Basically, yes. It's interesting that you refer to them that way; it
> > brings to mind locales, which are another type of namespace, and
> > suggests the possibility of unifying lexical environments with
> > locales. I think doing that would be a bad idea, though, because
> > locales are shared mutable state, and it would be good to have less of
> > that rather than more. Hence, my proposal applies only to lexical
> > scopes.
> >
> > The idea is that, if I have something like:
> >
> > f=. {{
> > a=. 5
> > b=. 6
> > g=. {{ ... a ... }}
> > a=. 7
> > ... }}
> >
> > When g (or, rather, the verb it denotes) is created, it will remember
> > and carry around the lexical environment in which it was created,
> > which includes an association between a and 5. (Since g refers to a,
> > we say that it 'closes over' it. The term 'closure' comes from graph
> > theory.) This association is frozen at the time g is created; hence,
> > it never sees a=5. The environment is manifest in the AR as a list of
> > key-value associations; users can twiddle or create their own
> > environments, but should not generally have much call to.
> >
> > Obviously, this comprises a break to compatibility, but the fallout
> > seems fairly minor. Such name punning would be quite confusing.
> >
> > Since closure only applies to lexical variables, this breaks no use of
> > globals. EG the following, at global scope:
> >
> > a=: 5
> > fn=: {{ ... a ... }}
> > a=: 7
> >
> > Will work just the same as it ever did.
> >
> > A question: should g close over b? It is not referred to directly in
> > g, but the latter might construct references to b using "., or a user
> > might ask for it when debugging. I vote no, because of the potential
> > for space leaks. g can include a dummy reference to b, if it really
> > wants; and perhaps a global toggle can be added for debugging
> > purposes. (This also relates to my comment in github issue #153.)
> >
> > What say?
> >
> > -E
> >
> > On Tue, 17 Jan 2023, Henry Rich wrote:
> >
> >> Is it about namespaces then? That is indeed a vexed question. I
> >> will take this under advisement. I will need more help I'm sure.
> >>
> >> Henry Rich
> >>
> >> On 1/17/2023 10:15 PM, Elijah Stone wrote:
> >>> It is the other way around--lack of closures means we must write
> >>> _more_ tacit code, not less. E.G.:
> >>>
> >>> {{
> >>> a=. something
> >>> {{ something referring to a }} A y NB. doesn't work
> >>> }}
> >>>
> >>> Whereas:
> >>>
> >>> {{
> >>> a=. something
> >>> (something referring to a) A y NB. works
> >>> }}
> >>>
> >>> I am proposing a mechanism to make the former work (among other
> >>> things).
> >>>
> >>> On Tue, 17 Jan 2023, Henry Rich wrote:
> >>>
> >>>> I don't follow any of this thread, because I don't understand what
> >>>> is missing from standard J. I find J adequate for everything I want
> >>>> to do. What am I missing?
> >>>>
> >>>> I can see that if you want to write all-tacit code you have trouble
> >>>> if you need to feed a verb result into a modifier.
> >>>>
> >>>> Suppose though that I am content with writing explicit
> >>>> definitions. What do I need beyond the standard language, and for
> >>>> what use case?
> >>>>
> >>>> Henry Rich
> >>>>
> >>>> On 1/17/2023 9:23 PM, Elijah Stone wrote:
> >>>>> (Curried modifiers, as you say, are a solution, but, again,
> >>>>> another half-solution.)
> >>>>>
> >>>>> On Tue, 17 Jan 2023, Raul Miller wrote:
> >>>>>
> >>>>>> Here, I suspect that you're only getting noun values in your closure
> >>>>>> -- you'll have to sprinkle those noun references with something like
> >>>>>> `:6 if you want anything else. That's probably not a huge problem.
> >>>>>>
> >>>>>> But, thinking about this, personally I'm not seeing a lot of
> >>>>>> motivation for this approach, either. (What problems would this
> >>>>>> solve?
> >>>>>> I'm sure there are some great motivating examples out there. And
> >>>>>> closures certainly have a lot of popularity. But... position in a
> >>>>>> list
> >>>>>> can be thought of as being conceptually analogous to a variable,
> >>>>>> so it
> >>>>>> should be apparent that we already have some support for the
> >>>>>> algorithmic role of closures.)
> >>>>>>
> >>>>>> (I should perhaps also note, here, that conjunctions and adverbs
> >>>>>> which
> >>>>>> have verb results are self-currying.)
> >>>>>>
> >>>>>> Anyways... I'm not thinking particularly deep thoughts here -- I'm
> >>>>>> just reflexively reaching for motivating examples (which might
> >>>>>> assist
> >>>>>> in forming some of those sorts of thoughts).
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> --
> >>>>>> Raul
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Jan 17, 2023 at 7:01 PM Elijah Stone
> >>>>>> <elro...@elronnd.net> wrote:
> >>>>>>>
> >>>>>>> I suggest:
> >>>>>>>
> >>>>>>> [x] u &:: (k;v;k;v...) y
> >>>>>>>
> >>>>>>> Will evaluate u with bindings kvkv... (raveled) active. Should
> >>>>>>> work for both
> >>>>>>> explicit and tacit. Implementation is allowed to coalesce;
> >>>>>>> e.g., u &:: (k;v)
> >>>>>>> &:: (k;v) `'' may be rendered u &:: (k;v;k;v), deduplicated, &c.
> >>>>>>> Substitution also ok; eg (f%#) &:: ('f';+/`'') becomes +/%#.
> >>>>>>>
> >>>>>>> I would like for verbs defined inside of explicit verbs to be
> >>>>>>> implicitly
> >>>>>>> closed; this is obviously a compat break, but.
> >>>>>>>
> >>>>>>> On Tue, 17 Jan 2023, Elijah Stone wrote:
> >>>>>>>
> >>>>>>> > I don't love the proposal, as I think a conception of verbs as
> >>>>>>> first class
> >>>>>>> > should involve _less_ hackery with representations, not more.
> >>>>>>> But I don't
> >>>>>>> > feel that strongly either way.
> >>>>>>> >
> >>>>>>> > More fruitful, IMO, would be to work out how to add closures,
> >>>>>>> as I think
> >>>>>>> > there
> >>>>>>> > is a more urgent need for that (u./v. is a band-aid). Perhaps
> >>>>>>> taking
> >>>>>>> > inspiration from kernel (but skipping the mutation!).
> >>>>>>> >
> >>>>>>> > On Mon, 16 Jan 2023, Henry Rich wrote:
> >>>>>>> >
> >>>>>>> >> I have never understood the zeal for having verbs return
> >>>>>>> verbs, but it
> >>>>>>> >> must be real if some are willing to use dangerous backdoor
> >>>>>>> hacks into JE
> >>>>>>> >> to achieve it. ARs make it possible to pass verbs around,
> >>>>>>> but executing
> >>>>>>> >> them requires dropping into explicit code. To remedy this, I
> >>>>>>> offer a
> >>>>>>> >> proposal, backward compatible with older J:
> >>>>>>> >>
> >>>>>>> >> 1. (". y) and Apply (x 128!:2 y) to be modified so that if
> >>>>>>> the result of
> >>>>>>> >> execution is not a noun, it is replaced by its AR (instead of
> >>>>>>> '' as
> >>>>>>> >> previously).
> >>>>>>> >>
> >>>>>>> >> 2. (". y) and Apply to be modified so that if y (for ".) or x
> >>>>>>> (for
> >>>>>>> >> Apply) is boxed, the sentence is executed as usual except
> >>>>>>> that each box
> >>>>>>> >> is converted using (box 5!:0) before being put onto the
> >>>>>>> execution stack.
> >>>>>>> >>
> >>>>>>> >> The idea is that you can execute (".
> >>>>>>> >> expr-producing-AR,exp-producing-AR,...) without having to get
> >>>>>>> any
> >>>>>>> >> modifiers involved.
> >>>>>>> >>
> >>>>>>> >> Sentence execution can produce ARs, and can take ARs created
> >>>>>>> by verbs to
> >>>>>>> >> represent verbs and modifiers. That sounds pretty classy to
> >>>>>>> me, but I
> >>>>>>> >> don't know whether it's first-class.
> >>>>>>> >>
> >>>>>>> >> 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
> >>>>
> >>> ----------------------------------------------------------------------
> >>> 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
