I found the message below while searching the forum archives; since I am not subscribed to the Chat forum I am taking the liberty to respond here.
I guess in principle (@:) should be associative but in practice might not always be (just as (*) should be but it might not). I have encountered occasionally that situation but the verbs involved were complex and I just used the form that accomplished the task and kept going. Here is a simple example related to the digits of Pi, o=. @: Y=. 10x&^20 ((#: o (<. o o.)) -: ((#: o <.) o o.)) Y 0 Special code seems to be involved because, f=. #: g=. <. h=. o. ((f o (g o h)) -: ((f o g) o h)) Y 1 http://www.jsoftware.com/pipermail/chat/2012-March/004794.html : [Jchat] composition (was: J functors) Raul Miller rauldmiller at gmail.com Sat Mar 31 01:41:36 HKT 2012 • Previous message: [Jchat] composition (was: J functors) • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] ________________________________________ Here's a note on associativity from operad theory: "Associativity" means that composition of operations is associative (the function is associative), analogous to the axiom in category theory that f o (g o h) = (f o g) o h; it does not mean that the operations themselves are associative as operations. Anyways, I believe that (f @: (g @: h) -: (f @: g) @: h) y for all verbs f g h with monadic definitions which represent functions and all nouns y where this sentence is valid. And, I think that this also holds for @ where the rank of y is sufficiently constrained. I have been trying to construct counter-examples, but I have not been able to find one that does not also violate these constraints. (But I feel that buggy sentences are not valid for that interpreter.) Thanks, -- Raul On Fri, Mar 30, 2012 at 11:38 AM, Tracy Harms <kaleidic at gmail.com> wrote: > In reply to a message by J.M.Q. on the Programming forum on Functor, > turning the topic to the wider question of composition: > > I, too, favor seeing (@:) as the nearest J equivalent to composition. > Attempting to work with this idea in mind, in discussions where others are > not, has led to an awareness that others are usually quick to assume that > values are scalar, while I'm assuming scalars constitute just one edge > condition within the domain. The most common consequence of this is that > others tend to focus on programming techniques that can be used to support > collections, whereas I'm inclined to take support for collections as a > given. Also common is the way others describe operations on collections in > terms of their items, whereas I keep looking for ways to express that in > terms of the whole. This is simply a clash of paradigms. Insofar as I don't > meet other people in their assumptions, I'm being stubborn. My reluctance > to join them in their paradigms reflects how very much I like having > "collectedness" made tidy at the language level. > > I'm very happy you mentioned the absence of comprehensive associativity > with J's candidates for composition. This seems to bring up the question of > "purity," which I see as the question of whether our executable system > conforms to our mathematical ideals well enough to get what we want from > those ideals. Emphasis on "composition" in languages usually turns on the > narrow meaning of composition often expressed as the small-circle operator. > But the sort of benefits that come from support for this narrow composition > appear to be but a subset of a broader range of "composition" that are > similarly beneficial. J's verb trains are outstanding examples of > compositional power that departs from the narrow sense of f-smallcircle-g. > > Restricting our attention to the narrow sense for a moment, if neither (@) > nor (@:) have the associative property that is mathematically required to > examine things in terms of composition, how do we account for the benefits > that come with having these built in to J? It would be rash to abandon > mathematics toward that aim, but we also don't get to simply assume that > these modifiers have the sort of properties that we would naturally assume > in trying to make sense of this through math. > > I am of the opinion that the greatest benefits of J are those that involve > "composition," "composability," or something along those lines. My > experience has been that people who do not know J are not in a position to > help identify and elaborate these benefits. I remain particularly > interested in such identification and elaboration, and welcome > communication with others who share this interest. > > A point of reference I found particularly useful was a blog-post by Jon > Purdy, which I believe has been previously mentioned in the J fora. "Why > Concatenative Programming Matters " > http://evincarofautumn.blogspot.com/2012/02/why-concatenative-programming-matters.html > > In the same time frame I read that post I came to see J as a hybrid > language, incorporating both applicative and function-level forms. I intend > to write a text for the J wiki Essay section on this topic. For now, I can > summarize by saying that applicative form appears both near the "bottom," > with the first-order syntax of (noun verb noun), and at the "top," with the > second-order syntax of (anything conjunction anything). (Here "anything" > must be limited to the parts of speech that modifiers can take as > arguments, thank you.) J is applicative in these forms because the > arguments to functions are specified. In contrast, verb trains, epitomized > by (verb verb verb), are tacit. They omit function arguments, rather than > specifying them. The way J allows these two forms to be smoothly > interleaved may be the most outstanding aspect of the language. > > It is my opinion that J has much to offer the wider world of computer > programming. The topic of composition brings me to the particular way I am > working to help bring the benefits of J to a wider world. I am striving to > expose how composition, widely construed, lets programs be more simple, > accessible, and constrained. > > --Tracy > > > 2012/3/29 Jose Mario Quintana <josemarioquintana at 2bestsystems.com> > >> ... In my mind I have always thought that (@:), using the convention of >> enclosing between parenthesis code embedded in lines to avoid >> misinterpretations, is the closest to mathematical function composition >> because it operates on whole arguments. > > ... > > Yet, the associativity does not always hold for (@:), or (@), not even for >> a simple argument (and I do not even know if that is a feature or a bug). >> >> >> > ---------------------------------------------------------------------- ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
