I decided to study your first example of fork using trace. Unfortunately,
that revealed a design defect in trace:
require'trace'
trace '1 (5 ;fork 4 (; fork) [ (; fork 3) ; ] ) 2'
--------------- 1 Monad ------
fork
3
|value error: fork
| t_z=. (fork)(3)
Trace is rather crude in that it ignores the locale where it was invoked.
The workaround is quite simple, though perhaps not completely obvious:
lrA_jtrace_ =: 1 : '5!:5 < ''u'''
fork_jtrace_ =: 1 : ' 2 : (''u"_ '' , u lrA , '' v"_'') '
(you could also use _z_ instead of _jtrace_ but that is bad because it
promotes ignorance of locale mechanics and the whole point of using trace
is to learn about how J works.)
Anyways, here's the result (caution: long):
trace '1 (5 ;fork 4 (; fork) [ (; fork 3) ; ] ) 2'
--------------- 3 Adverb -----
;
1 : ' 2 : (''u"_ '' , u lrA , '' v"_'') '
2 : 'u"_ ; v"_'
--------------- 6 Bident -----
2 : 'u"_ ; v"_'
3
2 : 'u"_ ; v"_'3
--------------- 8 Paren ------
(
2 : 'u"_ ; v"_'3
)
2 : 'u"_ ; v"_'3
--------------- 3 Adverb -----
;
1 : ' 2 : (''u"_ '' , u lrA , '' v"_'') '
2 : 'u"_ ; v"_'
--------------- 8 Paren ------
(
2 : 'u"_ ; v"_'
)
2 : 'u"_ ; v"_'
--------------- 4 Conj -------
4
2 : 'u"_ ; v"_'
[
4"_ ; ["_
--------------- 3 Adverb -----
4"_ ; ["_
2 : 'u"_ ; v"_'3
(4"_ ; ["_)"_ ; 3"_
--------------- 5 Trident ----
(4"_ ; ["_)"_ ; 3"_
;
]
((4"_ ; ["_)"_ ; 3"_) ; ]
--------------- 3 Adverb -----
;
1 : ' 2 : (''u"_ '' , u lrA , '' v"_'') '
2 : 'u"_ ; v"_'
--------------- 4 Conj -------
5
2 : 'u"_ ; v"_'
((4"_ ; ["_)"_ ; 3"_) ; ]
5"_ ; (((4"_ ; ["_)"_ ; 3"_) ; ])"_
--------------- 8 Paren ------
(
5"_ ; (((4"_ ; ["_)"_ ; 3"_) ; ])"_
)
5"_ ; (((4"_ ; ["_)"_ ; 3"_) ; ])"_
--------------- 2 Dyad -------
1
5"_ ; (((4"_ ; ["_)"_ ; 3"_) ; ])"_
2
┌─┬─────────┬─┐
│5│┌─────┬─┐│2│
│ ││┌─┬─┐│3││ │
│ │││4│1││ ││ │
│ ││└─┴─┘│ ││ │
│ │└─────┴─┘│ │
└─┴─────────┴─┘
==============================
The first instance of 4 Conj in that trace is probably key to understanding
what is going on here. (If you don't understand that one, it's worth going
through the previous steps, if you do understand it, hopefully the rest
should be straightforward.)
Note also that the appearance of Trident in this trace means that there's
an opportunity to use the fork keyword again in the expression, if you
wanted. That might also be a fun exercise? If, perhaps, unnecessarily
verbose. But if you always avoid verboseness I think you miss out on
opportunities to learn - it's a mix of going between concise and alternate
verbose expressions which teaches you how to work with the expressions.
Anyways, that was a fun example to work through.
Thanks,
--
Raul
On Sat, Aug 23, 2014 at 11:08 AM, 'Pascal Jasmin' via Programming <
[email protected]> wrote:
> original verb2conjunction definition
>
> lrA =: 1 : '5!:5 < ''u'''
> v2c =: 1 : ' 2 : (''m '' , u lrA , '' n'')'
>
> Something I just figured out in J, is that the u"_ trick to pass either a
> noun or verb to a modifier does not need to be resolved at
> "compile/definition time", and can still be used to return a tacit result.
> so new definition of v2c
>
> fork =: 1 : ' 2 : (''u"_ '' , u lrA , '' v"_'')
>
> This turns v2c into a fork, with the extra capability of parsing N V N,
> and V V N as a fork.
>
> 1 (5 ;fork 4 (; fork) [ (; fork 3) ; ] ) 2
>
> ┌─┬─────────┬─┐
> │5│┌─────┬─┐│2│
> │ ││┌─┬─┐│3││ │
> │ │││4│1││ ││ │
> │ ││└─┴─┘│ ││ │
> │ │└─────┴─┘│ │
> └─┴─────────┴─┘
>
> from the above note the leftmost side without any parens is parsed exactly
> as if v2c was not there. This is because v2c is an adverb, and so the
> right side is parsed before it is. The other 2 calls to v2c do change the
> parsing to that of a conjunction.
>
> (5 ;fork 4 (; fork) [ (; fork 3) ; ] )
> 5"_ ; (((4"_ ; ["_)"_ ; 3"_) ; ])"_
>
> while typing (; fork) to bind arguments closest to it, does not reduce the
> total number of parentheses, by keeping the parenthesis close together, it
> can make a line more readable than widely spread deeply nested parenthesis.
> The above has the fork version more readable than its result, and it is
> faster to touchtype than shift90, and cursoring around.
>
> A reason to not replace v2c entirely is that v2c returns a noun while fork
> returns a verb. fork can be used inside a tacit expression with dependable
> results, but v2c will be more intuitive outside of a tacit expression
>
> linkC =. ;v2c
> linkF =. ;fork
>
> 5 linkC 1 linkC 2 ;4
> ┌─────────┬─┐
> │┌─────┬─┐│4│
> ││┌─┬─┐│2││ │
> │││5│1││ ││ │
> ││└─┴─┘│ ││ │
> │└─────┴─┘│ │
> └─────────┴─┘
>
> (5 linkC 1 linkC 2 linkF ]) 4
> ┌─────────┬─┐
> │┌─────┬─┐│4│
> ││┌─┬─┐│2││ │
> │││5│1││ ││ │
> ││└─┴─┘│ ││ │
> │└─────┴─┘│ │
> └─────────┴─┘
>
> 5 linkF 1 linkF 2 linkF 4 a:
> ┌─────────┬─┐
> │┌─────┬─┐│4│
> ││┌─┬─┐│2││ │
> │││5│1││ ││ │
> ││└─┴─┘│ ││ │
> │└─────┴─┘│ │
> └─────────┴─┘
>
>
>
> ----- Original Message -----
> From: Pascal Jasmin <[email protected]>
> To: "[email protected]" <[email protected]>
> Cc:
> Sent: Saturday, August 2, 2014 10:34:21 AM
> Subject: Re: [Jprogramming] parsing abuse, verb to conjunction
>
> thank you Raul,
>
> I do have a workaround for this issue:
>
> 3 (4 :('assert. y>0 label_. assert. x>0 label_. x+y') v2c) 2
> 5
>
> inserting label_. creates an internal multiline parsing without the
> multiple lines.
>
> Can automatically convert to the format too:
>
> cutdef
> =: (0 :)(1 : 'cutLF m')
> boxscan
> =:((&.>)/)(>@:)
>
>
> ('assert. y>0';'assert. x>0';'x+y') cutdef
> ┌───────────┬───────────┬───┐
> │assert. y>0│assert. x>0│x+y│
> └───────────┴───────────┴───┘
>
> 4 : (([, ' label_. ',])boxscan ('assert. y>0';'assert. x>0';'x+y')
> cutdef)
> 4 : 'assert. y>0 label_. assert. x>0 label_. x+y'
>
>
> Linda, in terms of selling it:
>
> Its a simple way to write a conjunction. If you assign it to a name, then
> users can use it as a conjunction without parens.
> There aren't that many examples of writing an adverb that returns a
> conjunction. This simple one can enlighten us in how such adverbs could be
> used, and provide a template for creating more advance ones.
> As a DSL tool, it allows entry of data and code with potentially fewer
> parens, and provide a left to right feel.
> While there is always an equivalent way to write a function composition
> with parens, it can provide a lazy way to extend a function composition. (A
> conjunction grabs the first term to its right and processes before the rest
> of the expression on the right... fairly similar to parens). With a naming
> convention that clarifies a conjunction, this may be considered a cleaner
> way to write a fork:
>
> (2 appendC 1 + ]) 2
> 4 3
> (2 , 1 + ]) 2
> 2 3
> ((2 , 1) + ]) 2
> 4 3
>
>
> The main purpose for me though is extensible functional code generation.
> Sometimes I want to extend a code string in a way that conjunction parsing
> helps avoid inserting parens around part of the existing built code string,
> or part of the new string, or parts of both.
>
> Another parsing abuse example:
>
> eval
> =: 1 : ' a: 1 : m'
> CONJ
> =: 2 : ' u (v eval)'
>
> CONJ takes a string representation of a conjunction to create an adverb
> that will consume 2 arguments on its right.
>
> If you wanted to have a dyadic verb parse both its arguments on the right:
>
> 4 (3) CONJ ', v2c'
> 3 4
>
> (3 CONJ ', v2c')
> (3)(2 : 'm , n')
>
> is an adverb roughly equivalent to 3&, except it will take its argument on
> the left instead of right.
>
> The reason you might want that is composition of adverb trains, or
> composing functions where you only get part of the information at a time,
> and flexibility as to whether a verb or adverb can be inserted into a
> composition.
>
>
>
>
>
>
> ----- Original Message -----
> From: Raul Miller <[email protected]>
> To: Programming forum <[email protected]>
> Cc:
> Sent: Saturday, August 2, 2014 8:23:36 AM
> Subject: Re: [Jprogramming] parsing abuse, verb to conjunction
>
> Here is an issue to be aware of:
>
> 1 (4 :'x+y') 1
> 2
> 1 (4 :'x+y' v2c) 1
> 2
> 1 (4 :('assert. x>0';'x+y')) 1
> 2
> 1 (4 :('assert. x>0';'x+y') v2c) 1
> (1) (2 : 0) 1
> m 4 : 0
> assert. x>0
> x+y
> ) n
> )
>
> The problem is that 5!:5 does not do proper serialization of multi-line
> explicit verbs. The result of 5!:5 is designed for use by 0!:0, and J is
> perhaps too simplistic in this regard. (paraphrasing my understanding of
> Ken Iverson's take on this issue: <<why would you want nested blocks? That
> means you are not labeling things adequately, which leads to unreadable
> code.>> though actually he would probably have said something far simpler,
> like "why do you need that?")
>
> Of course, many programmers love unreadable code, (consider ioccc as an
> example). So maybe for their benefit we ought to have nested blocks and a
> 5!:7 serialization mechanism which can be used in ". contexts?
>
> It's certainly something to think about, but it might be worth keeping in
> mind that there will always be machine limitations and that for
> computational symmetries to be valid they need someone to find a practical
> use for them.
>
> Thanks,
>
> --
> Raul
>
>
> On Sat, Aug 2, 2014 at 12:35 AM, 'Pascal Jasmin' via Programming <
> [email protected]> wrote:
>
> > this adverb returns a conjunction which is designed to turn any dyadic
> > verb into a conjunction purely for parsing convenience that a conjunction
> > can sometimes provide.
> >
> >
> > lrA =: 1 : '5!:5 < ''u'''
> > v2c =: 1 : ' 2 : (''m '' , u lrA , '' n'')'
> >
> >
> > 2 1 (, v2c) 3 + 4
> > 6 5 7
> > appendC =. , v2c
> > appendC
> > 2 : 'm , n'
> >
> > 2 1 appendC 3 + 4
> > 6 5 7
> >
> > if you don't put parens around the adverb and its verb argument, then it
> > treats the full y as the n argument to the resulting conjunction which is
> > usually not what you want since that is what the original verb would do.
> > But including one of the conjunction arguments inside the parens, turns
> it
> > into an adverb which may provide useful parsing patterns.
> >
> > 5 , v2c 2 1 (, v2c) 3 + 4
> > 5 6 5 7
> >
> > 5 , (2 1 3 + 4)
> > 5 6 5 7
> > 5 (, v2c 2 1) (, v2c) 3 + 4
> > 9 6 5 7
> > 5 (, v2c) 2 1 (, v2c) 3 + 4
> > 9 6 5 7
> > (5 , 2 1 , 3) +4
> > 9 6 5 7
> >
> > 5 (, v2c) 3 (2 1 , v2c) + 4
> > 6 5 9 7
> >
> > 4 + 2 1 &, 5,3
> > 6 5 9 7
> >
> > ----------------------------------------------------------------------
> > 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
