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 sentence I thought
was tacit but didn’t show the benefits of
early binding.
Thanks for the explanation.
Am 16.02.20 um 15:23 schrieb 'Pascal Jasmin' via Programming:
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 commenting/complaining about is that explicit code should
substitute global variables inside the explicit code. This also applies to
verb definitions.
It will behave as you want if you use tacit code. The concept of "semi-tacit"
modifiers are explicit definitions that do not refer to x or y.
so,
(3) (2 : 'u"v') 1
3"1
does "compile"/substitute away the explicit code.
The reason this design/behaviour is useful is that you can use explicit code to
late bind to variables, and tacit code to early bind. J would need a constant
directive to consider substitutions.
One method to get what you want for code that uses constants that are usefully
changed prior to load is to have an init_verb called at the end of the script
that reassigns (tacit) verbs based on constant values.
On Sunday, February 16, 2020, 09:02:47 a.m. EST, Hauke Rehr
<[email protected]> wrote:
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 I use it when the arguments have already
been given when defining the verb.
Furthermore, this may be arbitrarily deeply nested.
Say you build a couple of conjunctions atop of
each other, you use the derived verb to define
another one and maybe a library on top
of them where it will be called routinely.
It is a good idea to evaluate constant expressions
as soon as possible and that’s why J does it in the
case of functions. I don’t see any reason to treat
conjunctions differently.
Maybe I’ll make up a resource demanding example
but the point should be clear without.
Am 16.02.20 um 10:22 schrieb bill lam:
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) {~ ], 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 constant nouns,
constant expressions are not substituted in c’s body (not expected)
I would not want m c n to be evaluated time and again
when some part of it, just like in the case of the verb above,
could be evaluated once when defining the derived verb.
This should result in major savings of computational
resources so I’d have expected J to do this.
could anyone tell me why this is different from verbs?
kind regards,
Hauke Rehr
(Jena, Germany)
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
--
----------------------
mail written using NEO
neo-layout.org
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
