Further to Raul’s response, also worthwhile to compare the following … (note I have removed the “. for evaluation to clarify the (0:0) used below):
myStruct1=: 0 :0 v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 ) myStruct2=: 0 :0-.LF v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 ) myStruct1 v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 myStruct2 v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 So myStruct2 just has the LFs removed from the result of defining the Noun (0:0) which refers to the following lines up to the closing parenthesis ‘)’ as Raul explained. The “. then executes the resultant noun (which has LFs removed). HTH, Regards Rob > On 10 Feb 2016, at 10:29 PM, Matthew Baulch <[email protected]> wrote: > > Looking at this more closely now. I'm a bit puzzled about the use of -. > here. Obviously this is used here in dyadic form. In x -. LF the LF > characters are, of course, removed from x. What is the x here? I have seen > that it works--not doubting that. Just trying to work out how. Sorry. > There's probably something obvious I've missed. > > On Wed, Feb 10, 2016 at 12:52 AM, Raul Miller <[email protected]> wrote: > >> If you do not have good names for partial calculations, that might be >> a sign that you need to think a bit more about the abstractions you >> are using. It can be difficult for other people to read if you don't >> make sufficient effort to label your abstractions. >> >> Also, I would note that your 'c0' is not a combinator, as you are not >> using its dyadic definition. So you might want to use a different name >> for that one. Perhaps: >> >> v0=:c0 >> >> That said, if you really want to execute really long lines, you can do >> that using ". 0 :0-.LF and indented text. (You need the indentation >> because line feeds will not separate words here.) >> >> For example: >> >> myStruct=: ". 0 :0-.LF >> v0 p0 c1 p1 c2 p2 c3 p3 c4 p4 c5 p5 c6 p6 c7 p7 c8 p8 c9 p9 >> c10 p10 c11 p11 c12 p12 c13 p13 c14 p14 c15 p15 c16 p16 c17 >> p17 c18 p18 c19 p19 c20 p20 c21 p21 c22 p22 c23 p23 c24 p24 >> c25 p25 c26 p26 c27 p27 c28 p28 c29 p29 c30 p30 >> ) >> >> I hope this helps, >> >> -- >> Raul >> >> On Tue, Feb 9, 2016 at 4:59 AM, Matthew Baulch <[email protected]> >> wrote: >>> Suppose I wish to construct a complex, non-regular deeply nested >> structure: >>> to model some inherently non-linear system. A natural approach (for me, >>> anyhow) is to construct a library of combinators, or a domain specific >>> language, with which to specify the (boxed) structure. >>> >>> J rises easily to the task, and before long I'm looking at long function >>> trains of the form >>> >>> myStruct =: c0 p0 c1 p1 c2 p2 ... cN pN >>> >>> where the ci are (combinator) verbs, and the pj are (parameter) nouns. >>> Nice. Easy. >>> >>> Only trouble is, N may be large and J prefers such statements to sit on a >>> single line. Correct? I can split my definition: >>> >>> msPartA =. ..... >>> msPartB =. ..... >>> ..... >>> msPartX =. ..... >>> myStruct =: msPartA msPartB .... msPartX >>> >>> though this feels awkward. The most obvious issue is that the PartA, ..., >>> PartX are distracting; unless of course I can find a natural way of >>> splitting and naming them. Ideally, the parts should be as close to a >>> comfortable line width as possible. Again, awkward. If myStruct1 and >>> myStruct2 have the same partitioning scheme but myStruct2 (for instance) >> is >>> much larger than myStruct1, there will be many sparsely, or many >>> overpopulated lines. Awkward too. >>> >>> I love J. It handles complex regular data so elegantly. How can I bring >>> similar elegance to irregular data? Can my combinators be rescued, or >>> should I use another approach? >>> ---------------------------------------------------------------------- >>> 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
