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

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

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.



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

Reply via email to