[EMAIL PROTECTED] wrote:
Well, yes, unexpected side-effects are not so great, however, in this case they're sequestered behind junctions. In fact, the other post suggested using implicit backtracking for this (something that can have a real problem with *expected* side-effects). If you just think of junctions as 'Just Works', side effects are implementation detail.What if junctions collapsed into junctions of the valid options under some circumstances, so
my $x = any(1,2,3,4,5,6,7); if(is_prime($x) # $x = any(2,3,5,7) and is_even($x) # $x = any(2) and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that calling is_prime($x) modifies the value of $x despite it being a very simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for is_prime($x), is_even($x) and $x > 2 to all be true, because an any() junction was used. If an all() junction was used it would be quite a different matter of course, but I would see is_prime() called on an any() junction as returning true the moment it finds a value inside that junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the characteristics of a prime number?' and of course, $x has - several of them, in fact (but the count is not important).
To address your idea, problem is, you generally don't know whether you've been passed a junction (short of very specific type query), and writing code without being able to rely on the fact that (is_prime($x) && !!is_prime($x)) == false is Just Plain Evil. For example, something as simple as
if (is_prime($x)) { ... }
else { ... }may be buggy if $x is a junction. To make it work correctly, you will want to write
if (is_prime($x)) { ... }
if (!is_prime($x)) { ... }Evil, no? :)
Miro
