Dave Whipp wrote:
I'm thinking that the solution to this issue may be a little more
radical than to-date: don't permit junctions to be stored in $
variables! Instead, require junctions to use a twiggle, to alert the
reader that the surprises may be lurking.
my $x = 1|2; #error
my $|x = 1|2; #
Martin Kealey wrote:
> On Tue, 31 Mar 2009, Jon Lang wrote:
>> Another issue: what happens if conditional code mutates a junction
>> that it filtered? For example:
>>
>> $x = any (-5 .. 5);
>> if $x > 0 { $x++ };
>>
>> At this point, which of the following does $x equal?
>>
>> any(-4 .
On Wed, 1 Apr 2009, Richard Hainsworth wrote:
> 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
Yes -- and well put, thank-you.
The trick is that since con
On Tue, 31 Mar 2009, Jon Lang wrote:
> Another issue: what happens if conditional code mutates a junction
> that it filtered? For example:
>
> $x = any (-5 .. 5);
> if $x > 0 { $x++ };
>
> At this point, which of the following does $x equal?
>
> any(-4 .. 6) # the original junction get
Mark J. Reed wrote:
[I] wrote:
So I'd vote for going with simple semantics that are easy to explain --
that is, don't attempt implicit junctional collapse. Provide operators to
collapse when needed, but don't attempt to be too clever.
While it's easier to find clever programmers than to write
On Wed, Apr 1, 2009 at 11:49 AM, Dave Whipp wrote:
> The problem I see with this (other than implementation issues) is that it
> would lead to unintuitive behavior in some cases:
>
> my $x = one(10,20);
> if $x > 15 {
> # here, $x collapsed to "20"
> if $x > 5 { say "$x > 5" } else { say "not $
Jon Lang wrote:
[proposal that conditional statements should collapse junctions]
$x = +1 | -1;
if $x > 0 { say "$x is positive." }
else { say "$x is negative." }
I suspect that both codeblocks would be executed; but within the first
block, $x == +1, and within the second codeblock,
HaloO,
Richard Hainsworth wrote:
( $a <= any(-1,+1) && any(-1,+1) <= $b )(*A)
[..]
$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 junctio
HaloO,
Jon Lang wrote:
Another issue: what happens if conditional code mutates a junction
that it filtered? For example:
$x = any (-5 .. 5);
if $x > 0 { $x++ };
At this point, which of the following does $x equal?
any(-4 .. 6) # the original junction gets mutated
any(-5 .. 0,
On Wednesday, April 01 2009 07:38 am, Richard Hainsworth wrote:
> 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.
>
>
This email was mistakenly not sent to the p6l list.
Jon writes:
On Wed, Apr 1, 2009 at 12:54 AM, Richard Hainsworth
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) && a
I've been having some second thoughts concerning this. Here's where I
stand on it now:
In Perl 6, you have the following "decision points", where code may or
may not be executed depending on a condition:
if/unless/while/until/loop/when statements; if/unless/while/until
statement modifiers; short-
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 )
>>
>> 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 s
13 matches
Mail list logo
