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
