if $a != 1 | 2 | 3 {...}
they really mean one of:
if not $a == 1 | 2 | 3 {...}
if $a == none(1, 2, 3) {...}
or, expressed in current understanding of negated ops:
if $a != 1 & 2 & 3 {...}
if $a != all(1, 2, 3) {...}
They specifically do *not* mean
if $a != any(1,2,3) {...}
since that would always be true.
I don't think we can allow this situation to stand. Either we have
to make != and !~ and ne transform themselves via "not raising", or
we have to disallow negative comparisons on junctions entirely.
Opinions?
Larry
I'm of the opinion that disallowing negative comparison on junctions
is the best way to go. If I were better at this forensics stuff, I'd
have a cogent argument to backup my position, but as it is all I can
think of right now is this: if we make != comparison illegal on
junctions, perl can give the programmer a helpful message when they
forget whereas the other way, they just get unexpected behavior if
they forget that != does something different than usual.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
>We have a bit of a problem with negative operators applied to junctions,
>as illustrated recently on PerlMonks. To wit, when a native English
>speaker writes
>
> if $a != 1 | 2 | 3 {...}
>
>they really mean one of:
>
> if not $a == 1 | 2 | 3 {...}
> if $a == none(1, 2, 3) {...}
>
>or, expressed in current understanding of negated ops:
>
> if $a != 1 & 2 & 3 {...}
> if $a != all(1, 2, 3) {...}
>
>They specifically do *not* mean
>
> if $a != any(1,2,3) {...}
>
>since that would always be true.
>
>
unless $a = none(1,2)
>I don't think we can allow this situation to stand. Either we have
>to make != and !~ and ne transform themselves via "not raising", or
>we have to disallow negative comparisons on junctions entirely.
>
>Opinions?
>
>
I go with option 2b: leave the syntax the way it is, but fire off a
warning, not an error when someone does this.
-- Rod Adams
> I don't think we can allow this situation to stand. Either we have
> to make != and !~ and ne transform themselves via "not raising", or
> we have to disallow negative comparisons on junctions entirely.
>
> Opinions?
Making them DWIM here would be a mistake, since the dwimmery would disappear
if anyone refactored:
if $note != $do | $re | $me {...}
to the supposedly identical:
if $note != $do || $note != $re || $note != $me {...}
That would be a bad outcome...pedagogically as well as from a maintainability
point-of-view.
I'd say we have to disallow negative comparisons against explicit
(compile-time) junctions. That is, against expressions that explicitly use
|/&/^ or any/all/one/none.
Negative comparisons against implicit (run-time) junctions:
if $note != $bad_note {...}
still have to be allowed.
Damian
Hmm. I'll just that if != is implemented like this:
multi sub infix:<!=> (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
Luke
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
> Hmm. I'll just [mention] that if != is implemented like this:
>
> multi sub infix:<!=> (Any|Junction $a, Any|Junction $b) {
> !($a == $b);
> }
>
> Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case, and it's easy to explain that the magic of
the C<!=> is being applied before the magic of junctions.
Damian
Heh, I knew if I waited long enough I'd see arguments for both sides.
Okay, let's go with the "not raising". Ain't lingristiks wunnerfle.
Larry