Also.... if this is literally a closure:
example=: {{
a=. 1
b=. 2
{{ ". y }} y
}}
I think this would mean that either 'example' here could not be
represented using 3 : string, or that we would have a lot of closures
popping into existence where they previously did not exist. So... in
addition to my semantic questions, I guess I also am wondering about
the syntax.
--
Raul
On Mon, Jan 23, 2023 at 2:57 AM Raul Miller <rauldmil...@gmail.com> wrote:
>
> 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
