Hello everybody,
I recently stumbled upon some at least
for me counterintuitive (read: puzzling) behaviour:
In a verb like (>: X) {~ ], when X is a defined constant,
the constant expression (>: X) is substituted in the verb (as expected)
but in a conjunction M c N, when M and N are defined const
Why do you think there will be major savings of
computational resources? Can you give a concrete
example?
Sun, 16 Feb 2020, Hauke Rehr написал(а):
> Hello everybody,
>
> I recently stumbled upon some at least
> for me counterintuitive (read: puzzling) behaviour:
>
> In a verb like (>: X) {~ ], w
I don’t have any concrete example that’s actually
expensive in terms of time or space (where space
means “memory”) but in place of >: in the verb
example, there could be any function, it could
take hours. This is no less true for conjunctions.
And I don’t want this to be called each and every
time
this all behaves correctly (did not understand your initial post)
"N
"1
+/"N
+/"1
(2 : 'u"v y')N
2 : 'u"v y'1
3(2 : 'u"v y')N
3 (2 : 'u"v y') 1
3 (2 : 'u"v y') 1
(3) (2 : 'u"v y') 1
3(2 : 'u"v y')N
(3) (2 : 'u"v y') 1
M =: 3
M(2 : 'u"v y')N
(3) (2 : 'u"v y') 1
What you are actually
Sorry, I thought I had done it tacitly
but your examples seem to prove me wrong.
(Maybe I didn’t understand the concept
of “semi-tacit” and where it applies.)
Of course we want to have late binding
available but there are also cases when
early binding is preferred.
My confusion is due to a senten
Several misconceptions.
If the body of c refers to y, m c n produces a verb that operates on a
subsequently-given [x]/y. I will assume that is what you are using,
since the only way to produce a modifier is using an explicit definition.
In this case, you must distinguish between the executio
Early versions of J had a computed goto.
It was an interesting concept -- instead of "goto" a line, and then
proceed incrementally, it was "goto this sequence of lines (and then
you're done)". So, if you had a 10 line verb, with a line label for
line 4, and a test point on line 8, the computed got
Let us start with your verb example but with some specific values,
X=. 0 1 2
( test=. (>: X) {~ ] )
1 2 3 {~ ]
as you mentioned, the result of (>: X) becomes the left tine of the fork
that defines the resulting verb,
type'test'
┌┐
│verb│
└┘
which, presumably is meant to be use
All my fault :/
In the sentence that didn’t behave as expected,
I used a variant of my conjunction that actually
wasn’t defined tacitly: there were references to y
which kept m and n (and thus constant expressions
they were occurring in) from being evaluated when
the derived verb was built.
Sorry
