Here's an example of the utility (?) of this new style of J code: Consider Project Euler problem 6, Find the difference between the sum of the squares of the first one hundred natural numbers and the square of the sum.
The normal solution to this would be (*:@:(+/) - +/@:*:) >:i.100 . But this uses both +/ and *: twice--wouldn't it be nice to eliminate the duplication? nest2Box and gTxt are taken from http://www.jsoftware.com/svn/DanBron/trunk/environment/anonymous_evoke2.ijs Dan's "don't" verb. d =: (]^:(1:`(<'@.')) nest2Box)@:gTxt boxname is a helper verb. Explicit verbs still can't return anything but nouns even if we pass them weird arguments, so boxname boxes a verb/adverb/conjunction, to be unboxed with >@: after the verb completes. boxname =: [: <@(]^:(1:`(<'@.')) nest2Box) 5!:2@< asverb takes a string that can be sent through d and makes it into a verb. fork makes a verb fork not once but twice: it creates a fork that, when passed verb arguments, will return another fork with the two tines applied to (not forked with) the arguments. asverb =: 1 :0 (>@) boxname 'result' [ result =. (d u) y : boxname 'result' [ result =. x (d u) y ) fork =: 1 : 0 (>@:) : boxname 'result' [ result =. x u y ) Then we have the final result, which is rather elegant if not as short as the original. atop =: '@:'asverb ('+/' (atop~ -fork atop)&d '*:') *:@:(+/) - +/@:*: ('+/' (atop~ -fork atop)&d '*:') >:i.100 25164150 I probably wouldn't recommend this style of coding as the best for any purpose, and I would certainly say not to use it in serious code, but it's somewhat similar to tacit code, but more extreme. Difficult but fun to work with, things simply explode when there are errors (you'll likely just get a syntax error), but very powerful. That said, we have essentially ventured into a different language than J, and the J implementation doesn't handle it all too well. boxname requires using 5!:2 as an intermediate, and fork is a kludge--the verb - applied to two verbs should give a fork, not a domain error. It's useful in the same way that C++'s STL is (admittedly, I have not used STL): powerful at the expense of bending the language almost until it snaps. Marshall On Sat, Jan 26, 2013 at 05:55:59PM -0500, Marshall Lochbaum wrote: > I half-agree with you. Of course the whole idea is crazy, but that > doesn't mean it's wrong so I'll ignore it. You're right about the > confusion that verbs returning arbitrary results can produce: if a verb > is passed another verb as an argument or returns a verb as an argument > it could easily make code fail in unexpected ways. > > But the syntax actually doesn't break; it's barely affected. The train > (V1 V2 V3) is still always executed as a fork and returns a verb. If a > non-noun shows up in one of the tines of a fork or during a conjunction, > verbs continue to act on it as if it is a noun. If it shows up on the > parsing stack, then it is treated appropriately, e.g. > +/ d'@:' * > +/@:* > gives the expected results (well, it surprised me that the form V1 N V2 > is accepted by the parser, since it will always result in a syntax error > after V1 runs in normal execution). If a verb returns something the > parser can't handle, you get a syntax error. > > Perhaps the idea of non-nouns being treated as nouns is a bit too > much--it does introduce a weird tacit/explicit duality where tacit code > is required to treat the thing as a noun and explicit code is required > to use its actual value. But even then, there's value in having > arbitrary J objects in boxes (box would throw an error when one of these > should be unboxed). These strike me as a sort of gerunds-done-right, > allowing for nouns that are as efficient as the original verbs, adverbs, > or conjunctions. It's a bit too late to propose replacing gerunds with > these constructs now, but I think it would have been a much better > solution to the problems that gerunds addressed. > > Marshall > > On Sat, Jan 26, 2013 at 05:25:37PM -0500, Henry Rich wrote: > > This whole idea of verbs returning any part of speech seems like a > > disaster. Perhaps after reflection it will be workable, but I would > > start by assuming that Ken and Roger weren't just thoughtless in > > restricting the range of verbs. > > > > It is pretty basic that every name must have a part of speech; > > otherwise how can you parse? And if verbs are unrestricted, if I > > see > > > > q =: V1 V2 V3 > > > > what part of speech can I assign to q? > > > > I think it's a bug and should be fixed. > > > > I do wish I had the old tacit language back, though. > > > > Henry Rich > > > > > > On 1/26/2013 5:03 PM, Marshall Lochbaum wrote: > > >First, let me say: wow. Using a (or the more general dont from Dan's > > >post, which I will use and call d), we can PUT ANY J OBJECT IN A BOX. > > >This means it can be passed around as a noun and invoked in an explicit > > >context. > > > > > > d =. (]^:(1:`(<'@.')) nest2Box)@:gTxt > > > ]infix =: <@d '/' > > >┌─┐ > > >│/│ > > >└─┘ > > > + (>infix) 3 4 5 > > >12 > > > > > >As long as we are inside the same tacit verb where d was called, its > > >output will be treated as a noun, despite the fact that it isn't: > > > > > > d@> '@&' > > >@ > > > ([: $ d@>) '@&' > > >2 > > > ([: |. d@>) '@&' > > >& > > > ([: (<"0) 3 3 $ d@>) '@&' > > >┌─┬─┬─┐ > > >│@│&│@│ > > >├─┼─┼─┤ > > >│&│@│&│ > > >├─┼─┼─┤ > > >│@│&│@│ > > >└─┴─┴─┘ > > > > > >Note that this clearly shows that the output of d@> '@$' is still a > > >list, even though it's displayed and treated as a single conjunction. > > >Once we exit the verb into an explicit context, the parser figures out > > >that it is dealing with a non-noun and starts treating it like one. > > > > > > use =: 3 : 'y 2 3 4' > > > use@:d '+/' > > >9 > > > > > >I don't think it's possible to use the result of d in a tacit context, > > >but I could be wrong. Of course explicit helper verbs that take boxed > > >things and apply them to other boxed things could be used, and they > > >could even be made polymorphic using 3!:0 . > > > > > >This is, of course, a bug. I can't find anywhere in the dictionary where > > >it says a verb must return a noun, but it's assumed throughout, and > > >explicit verbs are specifically made to throw a domain error rather than > > >return something that's not a noun. However, it's really cool and quite > > >possible useful--passing arbitrary J objects through verbs without the > > >overhead of gerunds or the hassle of names is very cool. > > > > > >Marshall > > > > > >On Sat, Jan 26, 2013 at 07:58:49AM -0500, Raul Miller wrote: > > >>On Sat, Jan 26, 2013 at 1:38 AM, Jose Mario Quintana > > >><[email protected]> wrote: > > >>>>I guess this is the final proof that given J and a sufficiently > > >>>>POWERful > > >>>>AGENDA, you can DO anything! > > >>> > > >>> agenda=. ]^:(1:`(<'@.')) > > >>> (atop=. (<'@') agenda 0) > > >> > > >>Or: > > >> > > >> a=: ]^:(1:`(<'@.'))&0@< > > >> atop=: a '@' > > >> type 'a' > > >>+----+ > > >>|verb| > > >>+----+ > > >> type 'atop' > > >>+-----------+ > > >>|conjunction| > > >>+-----------+ > > >> > > >>The pun is different, of course. > > >> > > >>Of course, the results are not necessarily consistent: > > >> > > >> a&.> '@&' > > >>+-+-+ > > >>|@|&| > > >>+-+-+ > > >> a&> '@&' > > >>@ > > >> > > >>But I suppose that since we already have inconsistent behavior for > > >>displaying complex objects, maybe that's ok? > > >> > > >>-- > > >>Raul > > >>---------------------------------------------------------------------- > > >>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 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
