Brent 'Dax' Royal-Gordon wrote:
Rod Adams <[EMAIL PROTECTED]> wrote:Actually, if one writes is_prime to have slurpy array passing a la Perl5, as I wrote in a different post, $x most certainly is a junction at this point.
Luke Palmer wrote:
What on earth does C< for (2..sqrt(3|5)) {...} > mean in the current2..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?
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.
Although this does beg the question: If by default one can't assign a junction to a variable, does this apply only in cases with an assignment operator, or does it also happen on parameter passing?
I've just reread Larry's post about normally disallowing storage of junctions in a lvalue. He covers the point about declaring parameters that are junctional, and the parameters are otherwise non-junctional. What is not clear here is whether or not the S09 talk about if a junction is inside another container (like a slurpy array), if it gets caught or not. The array itself is not a junction, but one or more of it's elements might be. So do we have to walk the entire reference tree if we are given a complex data type, looking for junctions? This is not an option, think no further than lazy lists to see why. So the other option is to have a runtime check, and as soon as a memory store containing a junction is encountered, then throw an exception. Even if this happens well after the parameter passing step. Hmm. Messy, but possible.
Only under
your notion of junctions as just another object with no autothreading
until the operator level will $x ever be a junction.
For the record, I've withdrawn that proposal.
All I want now is for autothreading to be explicit.
Or is it the case that C< .. > acts a bit like the old flip flop it used to be, and stop at the first true value it sees?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.
AFAIK, the concept of Junctional Lists has not been created yet, so what else would it return? A list of junctions? all of which are ($x|$x) or ($x|undef)?
Except for the absolutely massive amount of Perl5 code out there that will be hastily translated by people who don't trust the Perl6 <-> Ponie interplay, and the flocks of Perl5 programmers coming over without learning all the new features of their upgraded language, you're probably right.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.
-- Rod Adams
