So, what is the deeper issue? An initiate using j8xx interpreters could
easily refer tacitly to [x] and y from within tacit adverbs (and
conjunctions when using forks of j8xx interpreters) and write a version of
{{ y `:6 }} with a vengeance (illegally, of course); however, in J there is
an official obsession (in my opinion) restricting verbs to return nouns,
only nouns, and nothing but nouns. I have no idea about k, but DyalogAPL
at least allows the verb execute to return verbs,
(โ'+/') 1 2 3 4
10
BQN is going all in and grants all functions first-class citizenship. See,
Functional programming
https://mlochbaum.github.io/BQN/doc/functional.html#functional-programming
Will the pioneer of tacit programming be left behind? According to
Marshall, it has already happened. Does it matter? For the vast majority
of users, which follow the strong advice of the developers of J, DialogAPL,
and BQN included, namely, use tacit only for lightweight tasks and use
explicit for middleweight and heavyweight tasks, it hardly matters. Maybe
there would be just the minor occasional annoyance when a tacit solution
seemed within reach.
I am admittedly a user with special needs ;) I am a tacit fanatic, I
started porting a system from DialogAPL many years ago to J only after I
had convinced myself that the whole thing could be coded entirely in a
tacit manner. Moreover, because I am in the business of processing verbs
(algorithms) as much as processing nouns (data), tacit adverbial and
conjunctional programming matters a lot to me. The one or two readers left
at this point that might be interested to know why first-class citizenship
could make a world of difference for tacit adverbial and conjunctional
programming might like to continue reading a little bit more.
Once (tacit) verbs are allowed to take and produce any type of entity the
full power of tacit verbal programming is unleashed in the context of tacit
adverbial and conjunctional programming. In j8xx interpreters (and related
forks) this works because the structural verbs can still operate producing
expected results (in particular verbs, adverbs and conjunctions can be
boxed, thus, can be passed as arguments, and can replace cumbersome gerunds
and atomic representations) and adverbs and conjunctions can be verbed
(i.e., can be made to act as verbs) and be used to produce verbs, adverbs,
and conjunctions. There is no more guessing if this, that, or the other
form might help, one just can produce what one wants to produce (to my
knowledge, this is not really different from what other users of functional
programming languages, with first-class citizenship, do). As far as I can
see, BQN follows a similar approach albeit with peculiar means for entities
to play different syntactic roles.
The following gives a flavor on how this is done by producing a pipe of
verbs as an example. First, BQN, (taken from the reference above),
{๐โ๐}ยด โโฟ-โฟ(รห)
โโ(-โ(รห))
gauss โ {๐โ๐}ยด โโฟ-โฟ(รห)
Gauss 2
0.01831563888873418
(although, from my vantage point, the use of ๐ and ๐ is an eyesore).
Now Jx, a custom fork of a j8xx interpreter, following essentially the same
approach but entirely tacit,
(?:(<,'@:')) &>/ [: ^ - *~ ]:
^@:(-@:(*~))
(?:(<,'@:')) &>/ [: ^ - *~ ]: 2
0.0183156389
Finally, j903 requires a gerund and an adverb,
(^`-`(*~)) ((([ , (,<'@:') , ])/([.].))(`:6))
^@:-@:(*~)
(^`-`(*~)) ((([ , (,<'@:') , ])/([.].))(`:6)) 2
0.0183156
The j903 version does not seem too verbose compared to the BQN and Jx
versions but it required extra work because I do not carry in my head, nor
do I want to carry in my head, the particulars of how the atomic
representations of conjunctions are built. The above was a simple example
that j903 can handle relatively easily. However, once one is outside the
comfort zone things get tricky. Doubters can try to write a tacit version
of the conjunction INTEGRATE appearing in the following post (ignore the
fact that the calculus add-on is written explicitly),
[Jprogramming] Evaluating a Gerund Array
http://www.jsoftware.com/pipermail/programming/2015-April/041621.html
Extra big bonus, try to make it also anonymous and fixed... Good luck!
On Sun, Dec 26, 2021 at 9:44 PM Jose Mario Quintana <
[email protected]> wrote:
>
>
> 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)
>
> > > 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
