I think this may be a way to present it (function conjunction):

   fc=: 2 :'m,n'
   2 1 fc 3 + 4
6 5 7
   fc
2 : 'm,n'
   
  Linda


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of 'Pascal Jasmin' 
via Programming
Sent: Saturday, August 02, 2014 10:34 AM
To: [email protected]
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

Reply via email to