getnoun=. ".@:('0 : 0'"_)
$getnoun''
1 2 3
4 5 6
)
12
On Fri, Feb 12, 2016 at 2:41 PM, Raul Miller <[email protected]> wrote:
> Wrapping 0 :0 in an explicit verb should be possible:
>
> getnoun=:3 :'0 :0'
> $getnoun''
> 1 2 3
> 4 5 6
> )
> 12
>
> It's also possible to do this tacitly, but yeah, doing it tacitly such
> that it triggers when a verb is executed would be tricky (possible,
> but overly verbose to accomplish). Also, not sure if that would have
> any uses...
>
> Personally, I rarely even bother using the predefined (noun define)
> cover for this. The raw 0 :0 form is actually rather convenient.
>
> Thanks,
>
> --
> Raul
>
>
> On Fri, Feb 12, 2016 at 2:03 PM, Matthew Baulch <[email protected]>
> wrote:
> > Ok. That explains things well. So the the line(s) containing : behave
> just
> > as if : is an everyday conjunction. It's the lines AFTER : that are
> treated
> > specially.
> >
> > I suppose that's quite a clear design. I'll re-read the documentation.
> Like
> > you say, once I know what's going on, these subtle points are more likely
> > to stand out.
> >
> > ". does indeed have unlimited potential—over the domain of character
> arrays
> > anyway. I'm trying to wrap this construction in a verb so I can obtain
> > these multi-line definitions without explicitly calling ". . Just for
> > feelings of purity. It doesn't seem like this can be accomplished
> tacitly.
> > I'm starting to think that 0:0 has to appear in each definition, and so
> > defining such a verb may not be possible. Oh well.
> >
> > Thanks. : makes sense now.
> > On 12 Feb 2016 2:11 pm, "Henry Rich" <[email protected]> wrote:
> >
> >> > 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.
> >>
> >> No. But that isn't surprising when you understand what's going on.
> >>
> >> 0 : 0 creates a noun.
> >>
> >> Because conjunctions are executed before verbs,
> >>
> >> 0 : 0 -. LF
> >>
> >> is the same as
> >>
> >> (0 : 0) -. LF
> >>
> >> (0 : 0) creates a noun that can be used just as any other noun is used.
> >> You can add to it, subtract from it, execute it... The (-. LF) has
> nothing
> >> to do with the execution of (:). What I'm saying is, if you are OK with
> >> something like
> >>
> >> ".;._2 (0 : 0)
> >>
> >> [which feeds the result of (0 : 0) into a verb], you should ipso facto
> be
> >> OK with
> >>
> >> (0 : 0) -. LF
> >>
> >> which also feeds that result into a verb, just from the left this time.
> >>
> >> The (:) in (0 : 0) is executed WHEN (:) IS EXECUTED, i. e. at the
> >> appropriate time during the parse [see NuVoc for explanations]. After
> (:)
> >> has read its fill, execution of the sentence continues. So, you can have
> >>
> >> (0 : 0) ,&(".;._2) (0 : 0)
> >>
> >> 1 2 3
> >>
> >> )
> >>
> >> 10 20 30
> >>
> >> 40 50 60
> >>
> >> 70 80 90
> >>
> >> )
> >>
> >> 10 20 30
> >>
> >> 40 50 60
> >>
> >> 70 80 90
> >>
> >> 1 2 3
> >>
> >>
> >> Two (0 : 0) in one sentence [the parentheses are not required]! and
> >> executed right-to-left.
> >>
> >>
> >>
> >> (".) has unlimited potential, but often is put to mundane use. When I
> was
> >> starting with J I felt a frisson of daring when I used it, but now it's
> >> just another verb to me.
> >>
> >>
> >> Henry Rich
> >>
> >>
> >>
> >>
> >>> 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
> >>>
> >>
> >> ----------------------------------------------------------------------
> >> 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
