(Formatting came out weird; resending)
I need a little help understanding an obscure aspect of J grammar. I'm trying to write an adverb train in a way that intuitively "should" work, but doesn't, and I can't find a satisfying definition that does (I found a definition that works, but it's not satisfying). My motives are similarly obscure, so for those interested it's presented in the postscript. But in short, I'm trying to combine some utilities from the following sources: [1] Verb pipelines defined at: http://www.jsoftware.com/jwiki/System/Interpreter/Requests#verbpipelines , [2] and supported by: http://www.jsoftware.com/jwiki/DanBron/Temp/TrainToGerund . [3] Strand notation, presented at: http://www.jsoftware.com/pipermail/programming/2009-July/015565.html , [4] and defined at: http://www.jsoftware.com/svn/DanBron/trunk/environment/strand.ijs . The utilities of interest are eg from [1] (supported by t2g from [2]) and strand from [4] . What I want to write is: U =: (strand (<'[:')) (eg 1) but I can't. When I try to apply it, I get a syntax error. Can someone help me understand why, and how to work around it? Right now, I'm forced to generate code (along the lines of fancyStrand from [4]) to do so. I'd like a lighter-weight solution. Note that I *can* write [: f g h (strand (<'[:')) (eg 1) because it's equivalent to ( [: f g h (strand (<'[:')) ) eg 1 . But what I want is a reusable adverb, so I need [: f g h ( (strand (<'[:')) (eg 1) ) to work. But it doesn't. I know the problem has to do with strand's abuse of J's grammar, but right now I'm stumped on exactly what the issue is. -Dan === Motivation (long) === I love J's verb trains. Their definitions were inspired. Certainly, I can't think of a better replacement for (f g h) y <-> (f y) g (h y) et al. But these definitions do preclude others, in particular (f g h) y <--> f@:g@:h y . A minor result of this is the cognitive dissonance that f g h y differs from (f g h) y. That, one gets over within a few days of using trains. But a harder issue to overcome is that the re-usable equivalent of f g h y is f@:g@:h (or similar), which is longer and uglier. That is, the composition conjunctions (however spelled) make it hard to see the verbs; they drown the signal in noise. Plus they're harder to type. Put another way, verb pipelines, which are not uncommon, are muddied by the necessity of explicit composition. So, I'd like a utility that permits the syntax of trains to be leveraged to create verb pipelines. That is, a utility such that: [: f g h U <--> f@:g@:h for any number of verbs (not just 3); the cap indicates the end of the pipe (it's an arbitrary but mnemonic choice, and the underlying utilities would allow the user to select another if he desires, and similarly for the composition conjunction used). And, in case it's not clear, U is just the name of the adverb in question. Now, I have a close approximation of this, in the form of eg which is defined at [1] (supported by t2g defined at [2]); that utility allows me to write: (f g h) eg 1 to produce f@:g@:h & similar. But I am not entirely satisfied with this approach, because I find the requisite parentheses intrusive and somehow "binding". The code feels too constrained. So I want to combine eg with the strand notation I presented in [3] (and defined at [4]), to allow me to elide the parens, so that I could write: [: f g h U which feels much more "open". If the qualitative argument is unconvincing, then perhaps a quantitative argument will please: the minimal code that emits f@:g@:h based on eg is (f g h) A , which is 3 more than simply f g h . But, with strand notation, we could reduce this to 2, as in _ f g h U (recall the cap is user-selectable, so _ can be used instead of [:). This would justify applying the transformation to shorter trains, making it applicable more often. Furthermore, if/when J ever supports Unicode identifiers, we might be able to write this as: << f g h >> where << and >> are some fancy pair of Unicode braces (easy: <<=:[: and >>=:U ). That would be very satisfying. ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
