Thanks everyone. This (let's say) creative use of 0 : 0 makes sense to me now. I wonder if it's an accidental consequence of the implementation that allows an expression following the 0, or whether it's a deliberate design decision. Either way, it makes sense to have it documented. Can't see it in NuVoc or the Dictionary. Of course, I may have overlooked it.
Honestly, to obtain something simple like multi-line noun definitions, ". does seem like quite a heavy-handed tool. It does work however, so I probably shouldn't grumble. Cheers. On Wed, Feb 10, 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
