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" <[email protected]> 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 <[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
