Very briefly, the way I understand it, strict right-to-left grammar means
that a phrase like
f1 f2 f3 f4 x
translates to (the somewhat boring but often useful):
f1(f2(f3(f4(x))))
This is simple to understand for monadic functions. What about if there are
dyads? E.G.
x1 f1 x2 f2 x3 f3 x4 f4 x5
?
If you insist on strict right to left, you interpret this as:
x1, f1(x2 , f2(x3, f3(x4, f4(x5))))
essentially ignoring the dyadic nature of all functions.
Obviously, this isn't particularly useful.
You might object to my interpretation, saying what was really intended is
for each function to use its left and right arguments (dyadically) and pass
the result to the left. This is reasonable, but if that's the case, you've
already gotten away from strict right-to-left.
This may seem to be a minor consideration but it crops up all the time. How
can you evaluate
+/1 2 3 4
strictly right to left? You can't apply the reduction until you know what
function to use.
However, I believe the stated motivation of verb trains as they are handled
in J is to allow a richer combination of functions. Specifically, so
x (f g h) y
is (x f y) g (x h y) because this is succinct and a useful construct - it is
more general than the strict (and strictly undoable) right-to-left parsing.
If you want the preceding to evaluate as the stricter right-to-left
x f( g( h(y)))
you can do this simply by using @, @:, or [: as appropriate. If you insist
on strict r-t-l, the more interesting composition would have to be written
in the wordier form with its duplication of the noun arguments.
This argument reminds me of the original objections to r-t-l in general.
However, if you evaluated
-/1 2 3 4
left-to-right, as a naif might, this is equivalent to the less interesting
1-(+/2 3 4)
instead of the more interesting alternating sum. The same logic applies to
verb trains: if you really think about the implications, trains give you
more interesting constructs than a simpler r-t-l rule.
On Thu, Jun 4, 2009 at 8:54 AM, Michael Dykman <[email protected]> wrote:
> On Thu, Jun 4, 2009 at 6:38 AM, Don Watson <[email protected]> wrote:
> > Tacit J and the verb compositions, including forks and hooks
> > have significant advantages. However, there is one question that
> > really puzzles me.
> >
> > When longer trains of verbs (and other language components) are
> > created in Tacit J, why is the fork/hook grammar better than
> > right to left grammar?
> >
> > I haven't come across any explanation of the reason for the
> > change in grammar.
> >
> > Don
>
> I am probably the last person on this list who should pipe in here. I
> have been dabbling with the language for about 2 years now.
> Previously, I had spent 30+ years using computer languages, 20 of them
> professionally, mostly in what I lovingly refer to as "the
> bottom-feeding world of business app development". I have used C,
> C++, perl, Java, php, javascrpt.. all the predictable suspects and
> then some.
>
> I discovered J by accident, the subject of another post for another
> time. As I spent my first few hours fooling around, getting it do
> "something" I, I was gradually overcome by a sense of awe.. I wasn't
> sure what was going on here, but I was pretty sure that I had been
> working *way* too hard for the last 20 years.
>
> When I encountered train syntax, my first reaction was that it was the
> most arbitrary, academically-inspired nonsense I had ever seen.. but
> I was determined to grasp the syntax as I could see those patterns
> popped up a lot. As I struggled to rephrase my ideas into terms that
> I could grapple with in J, refactoring them down into the apparently
> arbitrary construct of the tacit train, it became apparent to me that
> nearly all of my logical constructs developed an inherent elegance to
> them in this form which was not obvious to me at all as I formulated
> the idea. I spent the next several months writing silly little
> programs, exclusively in tacit J until gradually it became second
> nature... I rarely use explicit J (but then again, I have no products
> in J)
>
> Others can better describe the formal properties of the train that
> lend it such power and elegance but I can tell that now, to me, every
> problem looks like a train. My work in 'conventional' languages has
> benefited as I see old algorithms in new light.
>
> --
> - michael dykman
> - [email protected]
>
> - All models are wrong. Some models are useful.
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
--
Devon McCormick, CFA
^me^ at acm.
org is my
preferred e-mail
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
