Re: Junction Values

[Damian Conway]

Rod Adams wrote:
I had not caught the difference between:
   use junctions;
   $x = 6|7|8;
   if is_prime($x) {...}
and
   if is_prime(6|7|8) {...}
There isn't one.
Is this new, or yet another important detail I missed along the way?
> Or is this a side effect of not being able to store a Junction, and can go 
away
> if C< use Junctions > is turned on?

Yes, it's a side-effect of the new default prohibition on junction assignments 
(though I'm still working hard to convince everyone that that prohibition 
cripples junctions and that having to <use junctions> before you can assign a 
basic Perl 6 scalar datatype to a variable is an abomination).


I will, however, question if this is optimal. Compare two simple cases: 
> C< $x == any(4,5,6) > and C< $x < all(4,5,6) >. Both of them are prime
> candidates to some optimizations, but the optimizations are likely rather 
different.
> If we pass the junction into the operator, then it can perform some custom 
tailored code,
> to make things much more efficient, instead of relying on a more 
generalized junction
optimizer to handle things.
Sure. That's why we have the ability to specify subroutines where junctive 
args are *not* autothreaded, by typing the corresponding parameter as taking a 
junction:

        multi sub infix:«==» (YourType $x, Junction $y) is symmetrical {...}
        multi sub infix:«<»  (YourType $x, Junction $y) is symmetrical {...}
These two multisubs can optimize for junctive arguments to their hearts' 
content.

I addressed earlier concept of how does perl know when there are side effects, 
> particularly with the execution path can weave to parts written in 
pure-parrot.
> In particular, if the  Patrick responded by implying that there was no such 
side
> effect protection. see:
http://www.nntp.perl.org/group/perl.perl6.language/19210 (my post)
http://www.nntp.perl.org/group/perl.perl6.language/19212 (Patrick's response)
I don't see that Patrick's response implies that at all. In fact, I think his 
statement that:

   >> Well, the ultimate answer is that both Dan and Patrick (and others)
   >> will negotiate the exact interface when we get to that point, and
   >> that we don't seem to be too concerned about it at the moment.
   >> (It could just be that we're both burying our heads in the sand
   >> hoping it'll be magically "solved" by the other.  :-)
   >>
   >> However, in working out these examples I'm fairly comfortable that
   >> it can be made to work at the Perl 6 compiler level if need be,
   >> although it will probably be a lot more efficient if we can find a
   >> way to do it within Parrot.
seems to confirm that detecting and reporting autothreaded side-effects is 
entirely possible.


If nothing else, to make sure you and Patrick have the same understanding of what's happening.
I'm sure we will.

This problem goes away completely with explicit autothreading. 
> perl would no longer be making assumptions about what to autothread, and 
what to carp over.

But that's the whole point of junctions! Namely that perl works it out for 
you. If you don't want that to happen then don't use junctions (and don't 
allow them to be used, by specifying C<no junctions>).

If you want explicit threading (I refuse to call it "autothreading"; if it has 
to be manually specified, it certainly isn't "auto") then use arrays instead, 
and thread your subroutines and operators over them using the explicit 
hyperoperator notation (see example below).


But bowdlerizing the concept of junctions isn't the answer.
I'm no longer doing that.
Or at least, I'm no doing anything anywhere close to as extreme as some 
of my other ideas over the last week or two. Which I can see perfectly 
well, in retrospect, how you felt I was gutting the power away from 
junctions, and how frustrating that must have been for you.
Thank-you for understanding that.

But I still don't like implicit autothreading, and likely never will. I 
don't know how to explain it, but it just feels very wrong. It's down 
there with using typeglobs to pass filehandles, which is thankfully 
history.
I understand your qualms, even if you can't nail down the exactly reasons for 
them.

However, I still disagree with them. I truly believe that junctions (including 
their autothreading behaviour) ought to be core to Perl 6...and not ham-strung 
in any way.

I appreciate that some people will not like the potential autothreading of:
        if is_prime($x) {...}          # Might possibly autothread
but I think it's sufficient to give those people:
        # At the top of the program...
        no junctions;
        # and then...
        if is_prime($x) {...}          # Can't possibly autothread
As for explicit threading: hey, you've already got it. Just use an array 
instead of a junction, and only allow explicit junctives. Either:

        # At the top of the program...
        no junctions 'assignment';     # Junctive constants okay
        # and then...
        if is_prime(any(@x)) {...}     # Explicitly threaded
or, even more thread-explicitly:
        # At the top of the program...
        no junctions 'assignment';     # Junctive constants okay
        # and then...
        if any is_prime«(@x) {...}     # Explicitly threaded

Damian