On 1/2/06, TSa <[EMAIL PROTECTED]> wrote: > HaloO, > > Luke Palmer wrote: > > The point was that you should know when you're passing a named > > argument, always. Objects that behave specially when passed to a > > function prevent the ability to abstract uniformly using functions.[1] > > ... > > [1] This is one of my quibbles with junctions, too. > > You mean the fact that after $junc = any(1,2,3) there is > no syntactical indication of non-scalar magic in subsequent > uses of $junc e.g. when subs are auto-threaded? I strongly > agree. But I'm striving for a definition where the predicate > nature of the junctions is obvious and the magic under control > of the type system.
I'm confused at the confusion. To me, junctions are just magical values, not magical scalars. In theory, one should be able to create junctions of arrays, hashes, or subs just as easily. my @junc = any( @a, @b, @c ); my %junc = any( %a, %b, %c ); Then, if @junc[2] == 9 { ... } would imply if @a[2] == 9 || @b[2] == 9 || @c[2] == 9 { ... } IMHO, one thing that may be causing issues with the junction concept is that I've never seen anyone talk about the implicit read-only behavior of a junction. To me, a junction would be required to be read-only (except for overall assignment). To modify the junction would be to overwrite it. So, given my $junc = any( $a, $b, $c ); If you wanted to add $d into there, you'd have to do it this way: $junc = any( $junc, $d ); Obviously, modifications to $a, $b, or $c would carry through. Doing this means that array, hash, and sub junctions make sense and behave no differently than any other readonly variable. In fact, this behavior seems mandated given the possibility of tying variables (or is this a Perl5ism that is being discarded in Perl6?) Rob