Rod Adams <[EMAIL PROTECTED]> wrote:
> Luke Palmer wrote:
> > 2..sqrt($x)
> >
> >What the hell does that mean? Do you get a junction of lists out? Or
> >does sqrt die because it's not expecting a junction?
> >
> What on earth does C< for (2..sqrt(3|5)) {...} > mean in the current
> state of junctions?
In the current state of junctions, the autothreading is done at the
level of the call to do_prime, so $x is never a junction. Only under
your notion of junctions as just another object with no autothreading
until the operator level will $x ever be a junction.
But if it somehow *did* become a junction, I would imagine something
like this would happen:
for (2 .. sqrt( 3 | 5 )) { ... }
for (2 .. ( sqrt 3 | sqrt 5 )) { ... }
for ( ( 2 .. sqrt 3 ) | ( 2 .. sqrt 5 ) ) { ... }
for ( 2 .. sqrt 3 ) { ... } | for ( 2 .. sqrt 5 ) { ... } #notionally
However, it's clear that the last step doesn't make a whole lot of
sense, since C<for> has no return value. Maybe C<for> would be
declared with a signature that didn't allow junctions at all.
> However, in the current scheme, if is_prime() is written to accept a
> slurpy list of parameters (either by design, or just a habit from the P5
> days), we can have:
I will readily admit that the behavior of junctions in a slurpy
subroutine call is suboptimal, and it might be a good idea to
reexamine it. However, I will also point out that most newbie
programmers probably won't use the @_ behavior, and likely won't be
using slurpy parameters either, while more experienced programmers
will know better.
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
"I used to have a life, but I liked mail-reading so much better."
