[Jprogramming] Nested structures. Idioms? Combinators?

[Henry Rich]

No, _2 (128!:2)&.>/\ y

Henry Rich

On 2/10/2016 5:16 AM, Henry Rich wrote:
> The operation you describe is
>
> _2 (128!:2)&.>\ y
>
> I think the current definition of 128!:2 is a better primitive 
> definition.
>
> I agree that it deserves a spot in the ASCII names.
>
> Henry Rich
>
> On 2/10/2016 3:59 AM, Matthew Baulch wrote:
>> Thanks for pointing that one out. Hadn't noticed it before. I find it
>> bizarre that it's regarded as a foreign. It seems like it deserves a
>> mention in the NuVoc page for ". y .
>>
>> Perhaps (128!:2) could be moved to the (currently undefined?) case of 
>> ". y
>> where y is a box array? I suppose we could require that:
>>
>> (1) 0 -: 2&|{:y
>> (2) items of 1-cells with even indices unbox to a character list
>> (3) items of 1-cells with odd indices unbox to a noun
>>
>> Each such pair would map to a box in the result  obtained by unboxing,
>> applying 128!:2, reboxing.
>>
>> Alternatively, we could have:
>>
>> (1A) 2 -: {:y
>>
>> and have an unboxed result.
>>
>> Or we could not bother and keep 128!:2. Hmm. Not sure what is best. I
>> suppose there is a mild efficiency advantage. I imagine the cost of 
>> parsing
>> x dwarves the cost of a box and unbox operation.
>>
>> Just an idea.
>> On 10 Feb 2016 1:32 pm, "Henry Rich" <henryhrich at gmail.com> wrote:
>>
>>> Look also at 128!:2, which takes a verb as a string argument and 
>>> applies
>>> that verb to y.
>>>
>>> Henry Rich
>>>
>>>
>>> On 2/9/2016 9:10 PM, Matthew Baulch wrote:
>>>
>>>> Thanks. I think this is what I was looking for.
>>>>
>>>> I was aware of 'noun define' but didn't know it could be used in 
>>>> this way.
>>>> Good point about c0.
>>>>
>>>> Documentation, I agree, is particularly important with this style 
>>>> of code.
>>>> My view is certainly not that definitions spanning multiple lines 
>>>> should
>>>> be
>>>> commonplace. It is nice to know, however, that it is possible.
>>>>
>>>> Cheers.
>>>> 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 <baulch.matt at gmail.com>
>>>> 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
>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm