[Jprogramming] Nested structures. Idioms? Combinators?

[Henry Rich]

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