Hmm... some questions then:
(1) What would a 5!:1 representation of closures look like? (Is it
basically "just an explicit definition"?)
(2) Can there be adverb/conjunction closures? Or only verb closures?
(3) Are closure symbols local names, or something different? (Can they
be updated?)
(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
