Coming from a functional programming background, I always find it jarring that x and y can't themselves be verbs. Even though I find the pseudo-English "adverbs", "adjectives", and "conjunctions" fascinating, they don't seem to fit with programming as well as verbs and nouns.
I've since come to understand some reasons for the design choice: it encourages less data abstraction, maybe makes implementation simpler or faster, etc. But when I program in J, I sometimes have a problem which would naturally (to me) be solved with higher-order functions, and I never know if I should use a conjunction or an adverb. No suggestions, just sharing my experience as a J user. Best, Alex On Mon, Aug 10, 2020, 2:48 PM Paul Jackson <[email protected]> wrote: > Thanks for your message. I know it has taken me a few days to respond, but > I have not been ignoring you. In fact I've spent several hours trying to > understand the issues with adverbs and conjunctions. It was only after a > careful re-reading, that I finally realized what you were telling me. > > foobar=. 1 : 0 > > x -10 > > ) > > 4 foobar > > _6 > > I don't believe I would ever have thought to try that without your message. > Now that I have, I believe the issue grows from Ken's initial Direct > Definition models. They only had two arguments: > > ⍺ and ⍵ > > The first J implementations I saw looked a lot like direct definition. > > As manager of the SAX project, it was my job to decide which features we > could include. As a consequence, I had some lengthy arguments with Ken over > his current thinking about how to provide features I now see in J. > Interesting as those stories are to me, they don't belong in this forum. > > Paul (formerly: [email protected]) > > On Fri, Aug 7, 2020, 9:10 AM Henry Rich <[email protected]> wrote: > > > Is it a bug? More a continuing penance for an initial faulty design. > > > > https://code.jsoftware.com/wiki/Vocabulary/com#Details note 11 describes > > the situation. > > > > In early J, the names u/v/m/n had not been invented, and an explicit > > modifier had only the names x and y to work with. x was what we now > > call u, and y v. Obviously, such a modifier was very restricted: to > > produce a modifier as we now know it, with access to u/v/x/y, the > > modifier would have to create the text after substituting its x/y, and > > have that reinterpreted by (3 : n) to create a verb. That definition > > didn't last long, but while it was in force a few simple system > > modifiers were written, for example > > > > bind > > 2 : 'x@(y"_)' > > > > Nowadays we would write 'u@m' or 'u@(m"_)'. The language wasn't even > > weaned and it had a compatibility problem! > > > > The 'solution', still in place today, was to inspect the text of the > > modifier. If no reference to u/v/m/n is found, the modifier is assumed > > to be old-style, and the names x and maybe y are defined as the modifier > > arguments. With your example, an adverb has no y, so y is left > > undefined and you get a value error. This error is detected when (1 > > now) is executed. You want a new-style modifier that defers execution > > until the (modifier+u/v) sees 'cat'. > > > > To get a new-style modifier, you have to have u/v/m/n in there > > somewhere. Just as you discovered. > > > > Henry Rich > > > > > > On 8/7/2020 11:28 AM, Paul Jackson wrote: > > > This is not where I began. I had lots of use of the m argument, but all > > of > > > it in quotes. It took me a while to isolate the problem to something > this > > > simple. Now that I have, I have also found other errors are signaled > with > > > the dyadic case of an adverb, and both cases of a conjunction. As my > > second > > > example shows, I can avoid the problem with an unnecessary use of the > > name. > > > I can provide details if anyone has trouble replicating the rest of the > > > issues. What I'm hoping for is a confirmation that this is a bug. > > > > > > Paul > > > > > > now=: 1 : 0 > > > y > > > ) > > > 1 now'cat' > > > |value error: now > > > | y > > > > > > now=: 1 : 0 > > > y [m=. m > > > ) > > > 1 now'cat' > > > cat > > > > > > JVERSION > > > Engine: j901/j64/android > > > Release-f: commercial/2020-06-12T10:01:40 > > > Library: 9.01.24 > > > J Android: 1.4.09/9/28 > > > Platform: Android 64 (arm64-v8a) > > > Installer: unknown > > > InstallPath: > > /storage/emulated/0/Android/data/com.jsoftware.j.android/files > > > Contact: www.jsoftware.com > > > ---------------------------------------------------------------------- > > > For information about J forums see http://www.jsoftware.com/forums.htm > > > > > > -- > > This email has been checked for viruses by AVG. > > https://www.avg.com > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
