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?



On Fri, Mar 2, 2018 at 9:26 AM, Henry Rich <henryhr...@gmail.com> 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

Reply via email to