This email was mistakenly not sent to the p6l list.
Jon writes:
On Wed, Apr 1, 2009 at 12:54 AM, Richard Hainsworth
<rich...@rusrating.ru> wrote:
Jon Lang wrote:
In "Junction Algebra", Martin Kealey wrote:
On Mon, 30 Mar 2009, Mark J. Reed wrote:
( $a <= any(-1,+1) <= $b ) ==
( $a <= any(-1,+1) && any(-1,+1) <= $b ) (*****A****)
Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS
shouldn't also be. Isn't it just syntactic sugar for the RHS?
I suspect not. Rather I think that
$a <= any(-1,+1) <= $b
corresponds to
$tmp = any(-1,+1);
$a <= $tmp <= $b
and thence to
$tmp = any(-1,+1);
$a <= $tmp && $tmp <= $b (*****B*****)
Quite how the lines I have labelled (****A****) and (*****B*****) are
different, I do not understand. Unless wrapping a junction in a variable
produces a different result.
That was my initial reaction as well. A closer examination of
Martin's message indicates that he tends to think that hitting a
junction ought to thread the entire program throughout the rest of the
lifespan of said junction, so that (e.g.) the thread that runs the
comparison "$a <= -1" in (*****B*****) is the same thread that runs
the comparison "-1 <= $b". OTOH, since (*****A*****) spells out two
separate junctions, it would thread each one separately; resulting in
four threads being used to resolve the expression. In theory, at
least; in practice, he's looking for ways to simulate such threading
without actually having to mess with all of the overhead that a
literal implementation thereof would entail.
In both cases, the problem arises when you apply a predicate to a
junction, and then use the junction within code that only gets
executed according to the truth of the predicate.
"Using a junction" implies the extraction of the eigenstates. That is being
frowned upon - I understand
I've been doing my utmost to avoid making said implication.
The possible solution to both of these: junctions collapse when they
hit conditional statements - but only within the "conditioned scope".
So: within the code block for the "if $x > 0" statement above, $x only
equals +1, since -1 didn't pass the test.
This is the sieving functionality. Since perl6 is being written explicitly
to avoid sieving out eigenstates, this will not happen.
What I'm hearing is that a decision has already been made on this
matter, so we're stuck with it no matter how counterintuitive the
results of that decision are.
Thus, "say $x" is the same
as "say 1". In the case of the range test, the code on the RHS of the
&& only executes if the code on the LHS evaluated to true; therefore,
when evaluating the RHS, "$tmp" doesn't include any of the
possibilities that would have failed on the LHS. That means that:
0 <= -1 | +1 <= 0
which is true, because using standard chaining semantics we have
0 <= -1|1 and -1|1 <= 0
Since the first condition is true (+1 >= 0) and the second condition is true
(-1 <=0), the compound is true.
Why you might want such a condition, I dont know. But that is the way
junctions are designed to work.
Right now, yes. I'm arguing that the way that they're designed to
work doesn't DWIM. Try a slightly different example:
0 <= $x <= 1 # 0 is less than $x is less than 1.
$x ~~ 0..1 # $x is in the range of 0 to 1.
I submit that most people would expect these two statements to be
conceptually equivalent to each other: they may go about tackling the
issue from different angles, but they should always end up reaching
the same conclusion. But as things stand now, if $x = -2 | 2, these
result in two very different conclusions: the first evaluates as true,
the second as false. This most certainly doesn't do what I mean until
I have been indoctrinated into the intricacies of Perl and learned to
think like it does - which runs directly counter to the principle of
DWIM.
Perhaps instead of 0 <= any(-1,1) <= 0, the programmer might want 0 <=
all(-1,1) <= 0, which is false.
You're assuming that the programmer gets to choose which junction he's
sticking in the middle of the comparison chain.
...becomes:
0 <= -1 | +1 && +1 <= 0
...which, obviously, is false.
The question really is what is the desired meaning of this conditional.
Yes. And my answer is that the desired meaning of "0 <= -1 | +1 <= 0"
is closer to "(0 <= -1 <= 0) or (0 <= +1 <= 0)" than it is to "(0 <=
-1 or 0 <= +1) and (-1 <= 0 or +1 <= 0)". The trick is to figure out
how to get this result without needing a nightmarish amount of
overhead to do it.
--
Jonathan "Dataweaver" Lang
