Marshall wrote:

"
The normal solution to this would be
(*:@:(+/) - +/@:*:) >:i.100
. But this uses both +/ and *: twice--wouldn't it be nice to eliminate
the duplication?

> 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

> > >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
"

See the following in the context of:
http://www.jsoftware.com/pipermail/programming/2013-March/031883.html

   f=. &{::

   twist=. ((0 f at 1 f) ; 2 f ; 1 f at 0 f) o box

   (evoke&6 o twist (*:`(+/)`-)) o >: o i. 100
25164150

The code is longer that the original redundant specific tacit version but
it is reusable,

   evoke&6 o twist (v0`v1`v2)
v0@:v1 v2 v1@:v0

Although to be really reusable we would like to write a magic verb such
that,

   (*:`(+/)`-) magic 100
25164150

   ,. @: |. @: i. 17 NB. An answer in
16
15
14
13
12
11
10
 9
 8
 7
 6
 5
 4
 3
 2
 1
 0

   magic=. < o twist x Apply (>: o i. y)

   (^.`(-/)`+) magic 100
1.3811466j3.14159265

From my perspective the duality is tacit/wicked tacit.


On Sun, Jan 27, 2013 at 2:03 AM, Marshall Lochbaum <[email protected]>wrote:

> 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
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to