Rod Adams asked:
> This sound reasonable enough?
Frankly, no. ;-)
Sorry, but your latest proposal sounds complex, multiply special-cased, and way too much of an imposition on the programmer (which is specifically what junctions are supposed to avoid).
I'm going to continue to strongly recommend that we stick with junctions that are simply another (fully assignable) kind of scalar value, and which always autothread in any scalar context that isn't explicitly typed C<Junction>.
To protect the innocent (or the timorous) I'm also going to recommend a C<no autothreading> pragma, which will prevent non-explicit junctions from autothreading.
And that's all I'm going to recommend.
Then, if you don't want implicit autothreading, you can turn it off completely: C<no autothreading>.
And if you want explicit (non-auto)threading, you can use an explicit junction, even under C<no autothreading>:
is_prime( any($x) )
And everywhere else, junctions will just Do The Right Thing, even to the point of ensuring that any side-effects on your unordered data are appropriately non-orderly. ;-)
I truly appreciate the thought and effort that all of you--especially Rod and Patrick--have put into this discussion, but I'm afraid I have to bow out of it now.
Damian
PS: FWIW, I'd have absolutely no objection to us adding a fifth core junctive type (perhaps C<Adjunction>, perhaps just C<Set> ;-) that has *no* associated predicate, but which implements full set semantics:
my $x = set(1..3);
my $y = set(1,3,5,7,9);
my $n = 2; $x | $y # set(1,2,3,5,7,9)
$x & $y # set(1,3)
$x - $y # set(2)
!$x # set(none(2)) ;-)
$x < $y # $x is a proper subset of $y
$x <= $y # $x is a subset of $y
$x == $y # $x is the set $y
$x ~~ $y # $x is the set $y
$n < $y # $n is an element of $y
$n ~~ $y # $n is an element of $y
set() # empty set
$x.values # list of elements of set $x
$x.powerset # power set of $x
$x x $y # cross product of $x and $y# etc., etc.
