Damian Conway wrote:
Rod Adams asked:
> This sound reasonable enough?
Frankly, no. ;-)
Sorry, but your latest proposal sounds complex, multiply special-cased, and way too much of an imposition on the programmer (which is specifically what junctions are supposed to avoid).
Funny. I thought it was simple and elegant. My explanation might have been complex, as well as the motivations, but I truly considered it a straight forward and simple solution.
As for "too much of an imposition on the programmer", that's essentially what I was asking for all along. To be imposed upon to decide when threading occurs. I won't apologize for that, or change my position on it. But I was making the imposition optional.
And, actually, now that I better understand your latest proposal, I realize how amazing close we are.
Then, if you don't want implicit autothreading, you can turn it off completely: C<no autothreading>.
And if you want explicit (non-auto)threading, you can use an explicit junction, even under C<no autothreading>:
is_prime( any($x) )
Change that C< any($x) > to C< »$x« >, and the important differences between our positions shrink dramatically.
Reason I don't like any() here is that $x already has a junctive condition on it. While any() with a single value does not change in the least how this will be evaluated in the long run, it could be confusing to wrap an all() junction inside an any() call. Doubling up the type works for all the types except none(). Use »« for an explicit call designator, and you revert to the type already in the junction.
Give me my »« as a secondary way of always explicitly threading, and I'll go away happy. You can keep the rest of your proposal the same. I'll just start using them wherever I think threading should happen, even if I never needed to use them in most of the places I will. It'll be a good visual to myself of what's going on.
Don't give them to me, and I'll frown for a while, but then likely get over it.
I truly appreciate the thought and effort that all of you--especially Rod and Patrick--have put into this discussion, but I'm afraid I have to bow out of it now.
I understand bowing out of this perfectly. There other tasks whose time I've raided for this discussion, and the backlog is starting to look pretty nasty.
But it has been a good and healthy discussion. Many things have come of it. Thanks to all the participants.
Now THAT is an even better idea than the separate Set class I was going to champion whenever I next had time for such a thing!
PS: FWIW, I'd have absolutely no objection to us adding a fifth core
junctive type (perhaps C<Adjunction>, perhaps just C<Set> ;-) that
has *no* associated predicate, but which implements full set semantics:
my $x = set(1..3); my $y = set(1,3,5,7,9); my $n = 2;
$x | $y # set(1,2,3,5,7,9) $x & $y # set(1,3) $x - $y # set(2) !$x # set(none(2)) ;-) $x < $y # $x is a proper subset of $y $x <= $y # $x is a subset of $y $x == $y # $x is the set $y $x ~~ $y # $x is the set $y $n < $y # $n is an element of $y $n ~~ $y # $n is an element of $y set() # empty set $x.values # list of elements of set $x $x.powerset # power set of $x $x x $y # cross product of $x and $y
# etc., etc.
I support this concept fully!
-- Rod Adams
PS - Looks like Matt gets his wish. This juggernaut of a thread is coming to a close. I'd be happy to proof his summary of it if he gives me an advanced copy.
