[Jprogramming] constant substitution

[Hauke Rehr]

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 <hauke.rehr at uni-jena.de> 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