I don't understand this thinking: [1] It seems like v@(...) should work just fine to extract relevant state from a larger bag of state.
[2] The proposal used v every step of the way rather than as the final stage. Is there some good example that shows how using v every step of the way solves the "simplify the final state" issue? Thanks, -- Raul On Fri, Mar 2, 2018 at 9:26 AM, Henry Rich <[email protected]> wrote: > The purpose of v is to allow u to create more state passed between > iterations than is needed in the final result. One problem with > > u/\. currently is that you might want to pass a big table between executions > of u but retain only an atom for the final result; without v you have to > have the entire table, from each execution, in the final result. > > So your u might produce something like (atom ; big table) while v is defined > as (0&{::) and the overall result is just a list of atoms. > > In short, v is required for a full solution. > > hhr > > > On 3/2/2018 9:12 AM, Raul Miller wrote: >> >> 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, >> > > > --- > 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
