Like I said: a closure takes the form u &:: (k;v;k;v...), which evaluates u
with bindings k;v;k;v... active. Thereby 5!:1 and 5!:5 trivially obtain.
u can be a proverb, or a tacit verb containing proverbs, but in that case
there's no reason not to eagerly bind, so eg f &:: (f;+`'') is equivalent to
+.
(2) Can there be adverb/conjunction closures? Or only verb closures?
I see no reason to exclude them. Obviously &:: wouldn't work then; I imagined
perhaps doing something like 1 :(<code;<k;v;k;v...). This wouldn't work for
tacit modifiers; something can perhaps be worked out, but I don't think it's a
high priority either way.
(3) Are closure symbols local names, or something different? (Can they be
updated?)
Lisp/javascript closures are mutable data. But obviously it would be very bad
if you could mutate the environment, since it's just an array. So updates
should be legal, but apply only to the current execution of the verb to avoid
'spooky action at a distance'. E.G.:
{{
a=. 5
f=. {{ a=. 1+a }}
a=. 7
(f;f)'' }}''
would give 6;6.
On Mon, 23 Jan 2023, Raul Miller wrote:
Hmm... some questions then:
(1) What would a 5!:1 representation of closures look like? (Is it
basically "just an explicit definition"?)
(5) What would a 5!:5 representation of closures look like? (A script
assigning the current values followed by the closure's function
definition?)
Thanks,
--
Raul
On Sun, Jan 22, 2023 at 9:24 PM Elijah Stone <elro...@elronnd.net> wrote:
(And yes, this would cause trouble for corecursion; but I think that's fine.
There are however tricks with binders that could be used to work around it if
desirable.)
On Sun, 22 Jan 2023, Elijah Stone wrote:
> The way I was imagining it, the effect would be that verbs in lexical scope
> would be eagerly bound modulo definition order. There would be no
> complication added to the object model.
>
> On Sun, 22 Jan 2023, Raul Miller wrote:
>
>> A problem with closures is that a complete implementation might
>> require a radical change in J's memory management mechanisms (and also
>> introduce difficulties for mechanisms like gerunds or 5!:n).
>>
>> Currently, J's arrays are trees, and verbs, adverbs and conjunctions
>> are arrays in this sense.
>>
>> With closures, verbs might become digraphs because J allows undefined
>> names in tacit verb definitions.
>>
>> To resolve these issues, closures might only be allowed to preserve
>> noun values. But introducing some sort of "complete local copy" aka
>> "snapshot" mechanism for verbs adverbs and conjunctions might also be
>> viable?
>>
>> 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
