Sorry. It would be more clear if I said 'the second zero'. I'm referring to the expression defining a verb to operate on the result of 0:0 as the left argument. It has been set as -.LF thus far in the discussion.
Forgive me if I'm wrong, but I don't see a discussion of 'expressions to the right of zero' (such as '-.LF' in '0 : 0 -. LF') in either of your links. I'd welcome any correction. Cheers. It's pretty well explained at http://code.jsoftware.com/wiki/Vocabulary/NounExplicitDefinition The question is, How would you know to read that? Suggestions welcomed. When you say "expression following the 0", I'm not sure which 0 you mean. : is the all-purpose entity creator; the left 0 says 'create a noun', and the right 0 says 'make that noun from the upcoming lines of input'. Full details are spelled out in several pages starting at http://code.jsoftware.com/wiki/Vocabulary/cor Henry Rich On 2/11/2016 12:55 AM, Matthew Baulch wrote: > 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 > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
