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 used monadically (otherwise, it will
simply ignore its left argument),
2 test 0 1
1 2
test 0 1
1 2
An almost equivalent definition is,
( test=. (>:X)&({~) )
1 2 3&({~)
test 0 1
1 2
However,
2 test 0 1
2 3
(but that is another story). The main point, so far, is to emphasize that
(<: X) is bonded to the dyadic verb ({~) and produces a monadic verb.
Can we do something similar with conjunctions? Yes. How? To illustrate
how one can do that, let us use the verb ({~) as the conjunction ( 2 : 'u
{~ v' ),
( test=. ((>: X) 2 : 'u {~ v' ) )
(1 2 3)(2 : 'u {~ v')
and the conjunction (2 : 'u {~ v'), with (>:X) as a bonded argument is an
adverb ((1 2 3)(2 : 'u {~ v')),
type'test'
┌──────┐
│adverb│
└──────┘
1 2 test
2 3
Of course, there might be instances where the use of a computed argument
bonded to a conjunction (or, for that matter, a computed argument bonded to
a verb) might not be advisable. (Incidentally, in the example above one
can use, u and v, or x and y, or m and n, in the conjunction's body;
however, I do not have a J901 interpreter handy to verify this is still the
case).
Do not try to code tacit conjunctions; as far as I know, it is an
impossible brain teaser. However, there are two ways to produce tacit
adverbs, one is as trains of tacit adverbs; the other, of course, is via a
primitive conjunction with a bonded tacit argument. Perhaps surprisingly,
one can go a very long way coding tacit adverbs combining these two forms
(at least if one is prepared to use arrays of atomic representations, in
place of gerunds, in some syntactic forms) and, in particular, tacit double
adverbs can be coded that way which effectively can take two arguments;
this is a counterpart of what is called currying in traditional programming
languages. Mind you, adverbial tacit programming is much more difficult
than tacit verbal programming (at least at the beginning).
I hope it helps
On Sun, Feb 16, 2020 at 10:38 AM Hauke Rehr <[email protected]> wrote:
> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
