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