I meant to write the following a couple of days ago but the infamous virus
stroke.  Oh well, better late than never...


There have been different kinds of issues with the tacit translator,
especially when one tries to abuse it; see, for example,

[Jforum] Tacit Definitions (jsoftware.com)
<http://www.jsoftware.com/pipermail/general/2005-June/022872.html>

> > Suppose s is a sentence [that] makes no use of x. or y. as arguments to
> > an adverb or conjunction
>
> A shame; on multiple occasions, I have wanted to do exactly this, and have
> had to write explicit code.


No kidding!  This simple explicit verb {{ y `:6 }} could be converted, in
theory, into a tacit verb; but, in practice, it seems to be a
challenging task even if "cheating" (i.e., using boxes) is allowed...   Are
there any takers?


> Suggestion: a new primitive adverb.  Call it 'n.'.  Like [:, it is
> syntactically regular, but semantically irregular.  Just as there is a
> rule for the evaluation of forks whose left tines are [: which takes
> precedence over the regular rule for the evaluation of forks, so are there
> rules for the evaluation of sentences containing n. which take precedence
> over the rules for evaluation of ordinary sentences:
>
> [x] u C (v n.) y
> [x] u C ([x] v y) y
>
> [x] u n. C v y
> [x] ([x] u y) C v y
>
> [x] u n. A y
> [x] ([x] u y) A y


This is a related issue, again, there is no apparent practical way to refer
tacitly to the arguments ([x] and y) of verbs (u and [v]) which are in turn
the arguments of tacit adverbs or conjunctions.  The language could be
extended to allow it; however, in my opinion, this would only cure another
symptom, the deeper issue is a weak J tacit
adverbial/conjunctional programming environment.

So, what is the deeper issue?

(To be continued in the Chat Forum...)



On Tue, Dec 21, 2021 at 9:24 PM Elijah Stone <[email protected]> wrote:
>
> With all this discussion of tacit modifiers, I fear their lower-order
> cousins are going out of style!
>
> The proof of completeness for trains
> (https://code.jsoftware.com/wiki/Essays/Trains#Proof_of_Completeness)
> contains two concerning notes:
>
> > Without loss of generality, assume that [sentence] s contains no
> > copulae; for if it does, d=.rhs (say), recursively replace instances of
> > d by (rhs)
>
> This transformation is problematic if rhs performs side effects; for it
> may cause those effects to be performed more than once, or not at all; or
> to be sequenced differently relatively to other side effects.
>
> In some cases, it may nevertheless possible to straightforwardly express
> an effectful verb tacitly.  For instance:
>
> {{ a=. 0 [ echo y
>     a + y + a }}
>
> becomes:
>
> (] + [ + ])  (0 [ echo)
>
> but some are not so straightforward
>
> {{ a=. 0 [ echo y
>     b=. 0 [ echo y
>     a + b + y + a + b }}
>
> It can be done, of course, but not without cheating (e.g. by using boxes,
> or by observing that + is commutative).
>
> Question: what is a clear and concise definition of the subset of
> effectful explicit verbs which may be made tacit without cheating?
>
>
> > Suppose s is a sentence [that] makes no use of x. or y. as arguments to
> > an adverb or conjunction
>
> A shame; on multiple occasions, I have wanted to do exactly this, and have
> had to write explicit code.  (In some cases, it is possible to get around
> the problem by passing a gerund to the conjunction; but that is not
> general; it is somewhat obscure; and frequently requires redundant [ or
].)
>
> Suggestion: a new primitive adverb.  Call it 'n.'.  Like [:, it is
> syntactically regular, but semantically irregular.  Just as there is a
> rule for the evaluation of forks whose left tines are [: which takes
> precedence over the regular rule for the evaluation of forks, so are there
> rules for the evaluation of sentences containing n. which take precedence
> over the rules for evaluation of ordinary sentences:
>
> [x] u C (v n.) y
> [x] u C ([x] v y) y
>
> [x] u n. C v y
> [x] ([x] u y) C v y
>
> [x] u n. A y
> [x] ([x] u y) A y
>
> Objections:
>
> - n. assumes that modifiers return verbs.  Something like 'u n. A'
>    _must_ be assumed to be a verb for this mechanism to make any sense.
>    Evaluation of A must be deferred, which is even more irregular than [:.
>
> - The common case of u C (f y) requires many parentheses if the input is
>    modified by a train:  u C ((f g h)n.).  (On the other hand, this is no
>    worse than the explicit code, which must write u C ((f g h) y).
>    NARS2000 suggests a mitigation in the form of higher-order modifiers:
>    assuming a higher-order ~, one might write (f g h)n. ~C u.  This is not
>    a serious suggestion.)
>
>   -E
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to