Lexical closures solve all sorts of problems and broadly make explicit code
much more expressive.
It's true you can implement them yourself. The pattern is: env&u@,&<; and
then you have to unpack the environment and the arguments manually. No one
does this, because it sucks. You might when u is a monad, and env is but a
single noun, or perhaps in _slighly_ more elaborate cases, but beyond that,
not really. And when the environment contains functions, forget about it.
You can see u./v. as clear demonstration of the need for closures. But those
are ad-hoc and require a complex relationship between caller and callee.
Closures are much simpler and more modular (i.e., they enable reasoning in
isolation). They are also more general.
In practice, we work around the lack of closures in a variety of ways. A big
part of it is that tacit verbs are closed over the nouns and modifiers they
refer to. All this means is that explicit verbs are hamstrung--unfair. And
that verbs referred to by tacit verbs are late-bound is a source of
consternation; self-effacing references, f., and the aforementioned u./v. are
solutions, but band-aid solutions only. Even keeping to tacit functions, if I
say:
{{
f=. ...
g=. ... f ...
h=. ... f ...
g C h y }}
And C does not use u./v. (addressed already), I am hosed. Cannot use f_:
because it is referred to multiple times. May not be able to f f. (or g f./h
f.) either, if late-binding is taken advantage of elsewhere, but anyway, why
should I have to? With lexical closure as the default, this will just work,
with no extra effort or thinking required. Ditto the case when any of g and h
is an explicit verb. Or when you want to assign any of these verbs to a
global (perhaps you are specifying a callback, to be called when some event
occurs).
One flaw in my proposal that occurred to me: it does not account for the
environments of modifiers. Explicit modifiers can perhaps be handled with
something like 1 : (code;env). How about tacit modifiers?
noun AR
Yes. I don't think this is a big deal. Users will twiddle environments by
hand only rarely.
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
