Larry Wall wrote:
On Thu, Feb 17, 2005 at 02:18:55AM -0600, Rod Adams wrote:
: The simple if is:
: : if $x ~~ (1,2,3,4) {...} # parens needed here since , is lower than ~~ : in precedence.
That is asking if $x is a list containing 1,2,3,4.
Quoting S04:
$_ $x Type of Match Implied Matching Code ====== ===== ===================== ============= Array Array arrays are identical match if $_ �~~� $x Array any(list) list intersection match if any(@$_) ~~ any(list) Array Rule array grep match if any(@$_) ~~ /$x/ Array Num array contains number match if any($_) == $x Array Str array contains string match if any($_) eq $x
And since there are no tell tell *'s on these saying that they are _not_ reversible, I must assume they _are_.
In C< if $x ~~ (1,2,3,4) {...} >, if $x is type Num or Str, then I see no way of reconciling your statement above.
: Same for unless/while/until. And all of this from the entirely useful C< : ~~ >. The S04 code describing @Array ~~ $Scalar (for Num/Str) uses : junctions, but I'd argue a better implementation would be a short : circuiting C< for > loop, even if junctions exist. It's just plain : faster that way.I was afraid someone was going to say that. And I now must convert my reservations about junction autothreading from "very disturbing" to "you've got to be kidding".
Junctions can short circuit when they feel like it, and might in some
cases do a better job of picking the evaluation order than a human.
According to Patrick, and since no one has corrected him, I will assume he is right,
perl6 -e "say1 'cat'|'dog'; sub say1 ($x) {say $x}"Should output "cat\ndog\n" or "dog\ncat\n". Now, if we allow Junctions to short circuit, and since there is no fixed order of values in a junction, we could get any of "cat\ndog\n", "dog\ncat\n", "cat\n", or "dog\n". What's that get us? non-deterministic output! I could handle non-deterministic *order* of output, because by the simple fact that you were using a junction, you didn't care about order.
Non-deterministic output! how fun!
Not to mention it contradicts S09: "... that routine is "autothreaded", meaning the routine will be called automatically as many times as necessary to process the individual scalar elements of the junction in parallel."
Now there is some wiggle room in there for short circuiting, but not very much.
: So what I see now for utility of junctions is thus:
: : - Common cases which C< ~~ > appears to handle for us suitably well.
Only if we make lists second-class citizens. The need for junctions
first became evident when we found ourselves filling the ~~ tables
with various sorts of weird non-symmetries.
So what other semantic makes sense for:
Str ~~ Array Num ~~ Array
which would better appeal to your sense of symmetry?
Besides, people were telling me that my Sets were not needed, because they could be rendered with Arrays and Hashes. I fail to see how junctions are that different.
: - Edge cases which, IMHO, do not merit the huffman level of several : single character operators. All of which can be accomplished without the : use of junctions, though not as gracefully.In my experience, English tends not to superimpose several values on a given noun at once.
Grace is important. Even more important is mapping naturally to human
linguistic structures, to the extent that it can be done unambiguously.
I realized that fairly early on. The situation I'm in is that while I don't agree with all the design initiatives that come out here, it's been the case that the more I think about them, the more I like them. I always achieve at least a state of ambivalence or better about it.: I see no need for junctions in core.
I do, and I'm not likely to change my mind on this one. Sorry.
With Junctions, it's been the case that at first I thought they were useful and cool, but the more I think about them, the more I dislike them.
I'll argue my case for a few more days, and if I haven't gotten anywhere by then, I'll likely give up.
-- Rod Adams
