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
<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
----------------------------------------------------------------------
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
