I'm responding on the chat forum, since I'm not sure my thoughts are relevant enough for the programming forum:
Reading over that fold proposal, I almost immediately want things to be different. Z: is complicated, the v argument is complicated and relates to Z:'s complications, we wind up with a lot of new primitives which work almost exactly like existing primitives but there's no visual cues for that. So, my thought experiment goes, let's try to discard some of that and see where it leads. Instead of building this up as a system independent of J, let's treat J as a specification language and this new mechanism as a modifier of those specifications. In other words, I think we can get away with just one adverb that gets the desired behaviors from an existing u/ u/\. u^: expressions. I am going to propose `. as that adverb. F. is just as viable, but having a different name makes it easier to distinguish between the proposals in when comparing and contrasting them. I am going to use U and V to represent verbs here, also, for much the same reason: to hopefully avoid some confusions. (I am basing my proposal on the original draft, so I want to start by focusing on what I propose to change.) ------------------------------ I think we can discard the v argument to the F... conjunction. For example, V@u/`. would replace u F.:v I know that V@u/`. looks more complicated, but I think we don't really need v and u/`. is simpler than u F.:] Also, my hope here is that the visual similarities will pay off. u/1 2 3 works just like u/`.1 2 3 so I think it's good that they are visually similar. With v gone, the left arguments to Z: go away also - we retain the _1 Z: meaning and get the effect of the 1 Z: meaning by having Z: as the final stage of our u verb. (We might even discard Z: itself - for example we could use ]:`. - but Z: is a suggestive name, so would keep it.) This lets us make Z: be an ambivalent verb. The monad terminates unconditionally (for use in @. structures) and the dyad takes a truth valued left argument to decide whether or not to terminate. The iterating folds seem to be motivated by the early termination behavior of ^:_ so let's have U^:_`. give us that (or, discard that sometimes unwanted feature), but let's revisit this in a moment... ------------------------------ In other words: F.: gets replaced by /`. F:: gets replaced by /\.`. Basically, `. does not treat its left argument as a black box (the t. model), but instead treats it as a white box (more along the lines of some of the d. implementation). We don't have a left-to-right / adverb, which is a bit awkward, so I propose we repurpose another adverb for that, in the context of `. expressions. But let's take a step back for a moment: Keep in mind that `. expressions are symbolic, so if someone did U//`. we should expect the (U/) expression to still be a black box. It's only the outermost / whose execution properties we're replacing. With that in mind, I would propose we use ~`. for left-to-right folds. It's a different visual pun, but we do at least have the "reverse left and right" aspect of the original ~ adverb to help serve our instincts: F.. gets replaced by ~`. F:. gets replaced by ~\`. ------------------------------ I think I've covered most of the possibilities, but I've sort of glossed over F. and F: and why they both exist and how to emulate them. And, to be honest, I don't really know why those were proposed as the most concise folds in the original proposal nor do I understand why they should both exist. Hypothetically, u~^:_`. and u^:_`. could serve, but there's nothing preventing F. and F: from being implemented. Following through on the reasoning which motivated proposal might make those be adverbs, but ... I really don't know so I'll stop here for now. Thanks, -- Raul On Fri, Mar 2, 2018 at 5:11 AM, Henry Rich <henryhr...@gmail.com> wrote: > Marshall, please criticize the proposal at > > http://code.jsoftware.com/wiki/System/Interpreter/Requests#Fold_.28strawman.29 > > Others' criticism welcome too. > > Henry Rich > > > On 3/2/2018 3:38 AM, Marshall Lochbaum wrote: >> >> There's no clean way to do it. If the result of the first invocation of >> f has the same type as the rest of the list elements, you can do >> >> f/ _2 (}. , f0/@:{.) l >> >> and if it has a different type you can check whether the right argument >> has this type (like your "signature structure", but implicit). >> >> One of my most missed features in J is a reduce with a specified initial >> element. Thus (l f/ e) would be equivalent to (> f&.>/ (<"_1 l),<e) but >> without the very large inefficiency of boxing everything. Of course >> dyadic f/ is already taken, so it would need another symbol. With this >> feature, you could use (_2 (}. f/ f0/@:{.) l) regardless of the >> properties of f. >> >> If your initialization comes before any of the processing and doesn't >> change the arguments (so that the first function invocation f0 is >> equivalent to (f[i0) for some initializer i0), then you can use >> (f/ l [ i0/ _2{.l), that is, separate the initialization from the >> function application completely. >> >> Marshall >> >> On Fri, Mar 02, 2018 at 01:51:39PM +0530, Arnab Chakraborty wrote: >>> >>> Hi, >>> >>> If f is a dyad, then >>> >>> f/ 2 4 5 >>> >>> means >>> >>> 2 f 4 f 5 >>> >>> where the rightmost occurence of f is invoked first. I am wondering if >>> there is a smart way to recognize this first invocation separately from >>> the >>> rest. This will enable me to perform some initialization inside f. By >>> "smart" I mean something smarter than the followung two: >>> >>> 1) using side effect like setting a global flag. >>> 2) adding some signature structure to the output of f (eg, 'inited'; >>> result), >>> and then checking the absence of this signature. >>> >>> Thanks. >>> ---------------------------------------------------------------------- >>> For information about J forums see http://www.jsoftware.com/forums.htm >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm > > > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
