The proposal for
u n: -> [x] u y (and then u n: M => (([x] u y)M) )
would work with this so that
". n: `:6
can consume "the output" though 2. suggests doing this. Would:
". '+';'/'; '1 2 3'
produce 3 boxes? a linear expression?
> willing to use dangerous backdoor hacks into JE to achiev
Please confine this to my proposal - not including n: .
It seems to me that if ". can produce any part of speech, and can be
applied to ARs, it can do anything. What is it missing? For example,
". (arnoun value) , (". '+&')
would produce the AR of (+&value) once you have written a suitable
On Tue, Jan 17, 2023 at 12:00 PM 'Pascal Jasmin' via Programming
wrote:
> > willing to use dangerous backdoor hacks into JE to achieve it
>
> Dangerous seems harsh.
But still meaningful, given that a mis-step here can crash J.
--
Raul
so an =: arnoun
an =: 1 : '<@:((,''0'') ,&< ]) m' NB. atomic rep of noun as an adverb (right
arg)
eval_z_ =: 1 : 'if. 2 ~: 3!:0 m do. m else. a: 1 : m end.' NB.1 : ' a: 1 : m'
aar =: 1 : 'if. isNoun ''u'' do. q =. m eval else. q =. u end. 5!:1 < ''q'' '
aar provides the functionality of an, an
With the proposed enhancement to ". you don't /need/ to produce a
modifier; you can execute the AR of the modifier.
Henry Rich
On 1/17/2023 3:12 PM, 'Pascal Jasmin' via Programming wrote:
so an =: arnoun
an =: 1 : '<@:((,''0'') ,&< ]) m' NB. atomic rep of noun as an adverb (right
arg)
eval_
are you saying that proposal is:
". ".'3&+'
3&+ NB. adverb?
On Tuesday, January 17, 2023 at 03:46:54 p.m. EST, Henry Rich
wrote:
With the proposed enhancement to ". you don't /need/ to produce a
modifier; you can execute the AR of the modifier.
Henry Rich
On 1/17/2023 3:12 PM, 'P
No, the proposal is
". '3&+'
produces the AR of 3&+
". (".'3&+'),(arnoun 5)
produces 8.
Verbs cannot produce anything but nouns; the ". verb produces the AR of
a non-noun result. ". can be applied to a sequence of ARs just as if
they were words in a sentence.
Henry Rich
On 1/17/20
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.
Verbs are first-class in J, in that they can be passed as ARs or by name
and invoked in an explicit verb. Nothing more is needed.
If a programmer is restricted to the tacit language (why? - I dunno)
verbs cannot be first-class. That seems to matter to some people. I
was trying to give them s
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%#) &:: (
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, ei
Could this be called templating?
> (f%#) &:: ('f';+/`'') becomes +/%#.
what if f were already defined? (usually substituted in verb phrases)
adverbs and conjunctions give this functionality.
I'm happy with the templating engine in this thread
http://www.jsoftware.com/pipermail/programming/20
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
Could this be called templating?
Not really. I think I was wrong to lead with &::, because it is a red
herring. The point is that lexical 'substitution' will work automatically.
(f%#) &:: ('f';+/`'') becomes +/%#.
what if f were already defined? (usually substituted in verb phrases)
(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. T
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 th
More ways to generate ARs doesn't hurt, but its not verbs returning non-nouns,
or a path (n:) to obtain non-nouns from a verb phrase, so then the proposal is
not meeting a major need.
repeating definitions,
eval_z_ =: 1 : 'if. 2 ~: 3!:0 m do. m else. a: 1 : m end.' NB.1 : ' a: 1 : m'
isNoun_z_
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 for
(To be clear, closures are orthogonal, from a language perspective, to
syntactically first-class functions. But they often appear together, and I
think the former more important, which is why I took the opportunity to bring
it up.)
On Tue, 17 Jan 2023, Henry Rich wrote:
I don't follow any of
Your ('X' Cloak(<@)("0) i.3 3) is interesting. It seems to display as
an array of boxed verbs. What would be the result if you opened that?
Can you apply all the verbs on an argument? What is the verb rank of
the boxed array, especially if the contents are verbs with different
ranks? How are
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
I think it's more about scope than namespaces, though namespaces are relevant.
Correct me if I'm wrong, but currently we run into problems when
dealing with locals in adverbs and conjunctions:
(a) We cannot see locals in a calling environment, and
(b) constructed verbs may refer to names in the
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
On Tue, 17 Jan 2023, Elijah Stone wrote:
The term 'closure' comes from graph theory.
(Although the connection is somewhat tenuous.)
This association is frozen at the time g is created; hence, it never sees a=5
Never sees a=7, rather.
/errata
---
On Tue, 17 Jan 2023, Raul Miller wrote:
(a) We cannot see locals in a calling environment
To add to this: it might be desirable to compose modifiers in such a way that
there are _multiple_ calling environments; you have to know which one to pick
for a given name.
---
the boxed verbs are limited. I mentioned that I can store as ARs instead. But
extracting 1 verb is a verb that can be applied:
(1 {:: (('X' Cloak ("0)(<@) )) 3 4 ) 2 3 4
6 7 8
Because "X cloaked" is applied "0, the results are assembled based on the shape
of y (i.3 3 in original example)
On Tue, Jan 17, 2023 at 11:09 PM Elijah Stone wrote:
> On Tue, 17 Jan 2023, Raul Miller wrote:
> > (a) We cannot see locals in a calling environment
>
> To add to this: it might be desirable to compose modifiers in such a way that
> there are _multiple_ calling environments; you have to know which
27 matches
Mail list logo
