HaloO,
Rob Kinyon wrote:
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 );
Hmm, and this is unflattened
my @joj = any( @a; @b; @c );
and
[EMAIL PROTECTED] --> any( [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL
PROTECTED] );
then? How long is the junctiveness kept?
Then,
if @junc[2] == 9 { ... }
would imply
if @a[2] == 9 || @b[2] == 9 || @c[2] == 9 { ... }
Uhh, and
if @joj[2] == 9 { ... }
should effectively means
if @joj[2;*] == 9 { ... }
with re-junctification of the sliced out arrays?
if any( [;] @joj.values[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 );
Like Ref values, then?
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.
Which first of all smells strongly like closure creation, that
is Code types! But shouldn't the read-only enreferencing be
more prominent notationally? Like
my $junc = any( \$a, \$b, \$c );
or through an Arglist (which means malice in German):
my $junc = any\( $a, $b, $c );
Otherwise I would strongly opt for value snapshotting
when the junction closure is created. And of course
the underlying functionality must be easily available
for user defined junctions. Things like set-, min-, max-
and sort-junctions come to mind...
Doing
this means that array, hash, and sub junctions make sense and behave
no differently than any other readonly variable.
Combined with lazy evaluation that yields on unavailable
values we enter the realm of constraint programming.
The grand unification then comes with multi threading
this concurrently. With side-effects that becomes *REALLY*
challenging!
In fact, this behavior seems mandated given the possibility of tying
variables (or is this a Perl5ism that is being discarded in Perl6?)
That is what := does these days? BTW, a rw junction is just
three chars around the corner:
my $junc = any:rw( $a = 1, $b = 2, $c = 4); #1
my $junc = any( $a = 1, $b = 2, $c = 4, :rw); #2
my $junc = any( $a = 1, $b = 2, $c = 4 ):rw; #3
$junc = 3; # means $junc.pick = 3?
I'm not sure which syntax of #1 to #3 really hits the junctions
creator with a named arg. And it might not support it for good
reasons! Just think what fun breaks loose if someone hands around
an array that contains (rw => 1):
push @array, (rw => 1);
$surprise = any([EMAIL PROTECTED]);
Or simply
my $junc := any( $a = 1, $b = 2, $c = 4);
So, do we want junctive assignment? Or should it complain like
my $val := 3; # error: can't bind constant
hopefully does.
--
