[Jprogramming] Closures; WAS: Verbs returning verbs

Henry Rich henryhrich at gmail.com
Thu Jan 19 15:02:58 UTC 2023 

I don't see that name_.. has any of the defects you see, except that it 
IS butt-ugly.

Performance is not to be dismissed.  You are talking about the parser, 
which for much user code is the heaviest-used part of the system.  
Ordinary local-symbol lookups take two reads from memory.  If you add a 
table search to that you have more than doubled the time spent in parsing.

I'm retiring from this thread because I don't know what a lexical 
closure is or why I ought to know.  I say this with the greatest 
respect.  If you think I'm missing something important, please explain 
it to me (privately).


Henry Rich



On 1/19/2023 12:16 AM, Elijah Stone wrote:
> I don't see why name_. is preferable to lexical closures.  It seems 
> more difficult to use and complicated to describe; not significantly 
> easier to implement; and it doesn't nest.
>
> Leaving aside performance (which can be resolved), I don't like the 
> semantics of name_.. .  Its sole virtue is that it admits corecursion.
>
> On Wed, 18 Jan 2023, Henry Rich 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 
>>>>>>>> <elronnd at 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

More information about the Programming mailing list