Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wrote:
>
>> Maybe you could have something like a filter function
>
> yes, but
>
>> that takes a
>> junction and a test condition and returns a junction of those
>> eigenstates from the original one that passed the test.
>
> But why is this a useful thing to do? I think that you're proposing, for
> compound junctions:
>
> ok any( 1|2, 1&2, 5|15, 5&15 ) where { $_ < 10 }
> === any( 1|2, 1&2, 5|15 )
...not really, no. The way I was looking at it, the above expression
is ultimately a junction of the values 1, 2, 5, and 15; no matter how
compounded the junction is, these would be its eigenstates. Since 15
would fail the test, anything having to do with it would be filtered
out. Exactly how that would work with a compound junction, I'm not
sure; as I said, I was thinking of the eigenstates as ordinary items,
not "nested junctions". But yes, I _was_ suggesting something that
transforms one junction into another.
That said, I'm also leery of compound junctions. Please tell me the
difference between:
any( 1|2 )
...and:
any( 1, 2 )
If there is no difference, then:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any( 1, 2, 1&2, 5, 15, 5&15 )
For that matter, I'm not seeing a difference between:
any( 1&2 ) # any of all of (1, 2)
...and:
any( 1, 2 ) # any of (1, 2)
If I'm not mistaken on these matters, that means that:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any(1, 2, 5, 15)
And I expect that similar rules hold for other compound junctions. In
short, I won't be surprised if all compound junctions can flatten into
equivalent simple junctions.
> To me, it still feels like you're thinking of a junction as a set of values,
> and inventing an operator specifically for the purpose of messing with those
> values. I do not see "values of a junction" as a meaningful user-level
> concept.
I'm pretty sure that Larry agrees with you here, seeing as how his
latest revision concerning junctions makes direct access to a
junction's eigenstates very difficult to arrange.
> I prefer to turn the problem around, and suggest a different
> operator, motivated by a different issue, and then apply that operator to
> junctions.
> Consider this statement:
>
> say (0..Inf).grep: { $_ < 10 };
>
> I would expect it to take infinite time to complete (or else fail quickly).
> It would be wrong to expect perl to figure out the correct answer
> analytically, because that is impossible in the general case of an arbitrary
> code block. So I instead propose an operator-based grep:
>
> say 0..inf G[<] 10;
> >>> [0..9]
>
> This “grep metaoperator” can be expected to analytically determine the
> result (of grepping an infinite list) in finite time.
>
> It might also be used
> to avoid curlies for simple greps:
>
> say @lines G~~ /foo/;
>
> The operator exists to filter infinite lists in finite time. But it also
> solves the junction problem:
>
> say (-Inf .. Inf) G== 3|4;
> >>> [3,4]
And how would it handle a compound junction (assuming they exist)? That is:
say (-Inf .. Inf) G== any(1|2, 1&2, 5|15, 5&15);
>>> ???
> $score = [+] 1|11, 1|11, 1+11, 1+11, 4;
I assume you meant:
$score = [+] 1|11, 1|11, 4;
> say max( 1..21 G== $score ) // "bust";
> >>> 18
...and the answer to that would be 16, right?
--
Jonathan "Dataweaver" Lang
