More junctions
Luke Palmer
junction, as it should be (QM-wise)?
$foo = 1 | 2 | 4
print $foo;
# Foo is now just one of (1, 2, 4); i.e. not a junction
If so, what is perl going to do about the computationally expensive
entanglement thingy?
$x = 0 | 1;
$y = 0 | 1;
$z = $x * $y;
print $z; # 0 with 0.75 probability and 1 with 0.25
# If 0 was printed, then $x | $y == 0
# If 1 was printed, then $x & $y == 1
Here, are $x and $y collapsed yet, or are they still in an entangled
superposition?
Luke
Deborah Ariel Pickett
> When junctions collapse, is that reflected back in the original
> junction, as it should be (QM-wise)?
>
> $foo = 1 | 2 | 4
> print $foo;
> # Foo is now just one of (1, 2, 4); i.e. not a junction
Just a sanity check, but is this kind of behaviour something we still
want from junctions? If we're trying to get away from the whole
"Quantum Superposition" name, why do we want to still have an implicit
collapse on $foo when it's used in certain contexts? To collapse like
this doesn't make sense unless you're still thinking in quantum terms.
Perhaps the above should just print JUNCTION(0x1234) or something, like
the other built-in types do. If you really want to collapse the
superposition, use an explicit collapse($foo) or observe($foo) or
pick($foo) or whatever you want to call it.
Just a thought from someone vaguely in the Cozens Camp.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep deb...@csse.monash.edu.au
"The city lights shine seaward, swirling in a trance, her eyes upon the water
alone in her last dance." - _Oh Life (There Must be More)_, Alan Parsons
Smylers
> Luke wrote:
>
> > $foo = 1 | 2 | 4
> > print $foo;
> > # Foo is now just one of (1, 2, 4); i.e. not a junction
>
> Just a sanity check, but is this kind of behaviour something we still
> want from junctions?
>
> Perhaps the above should just print JUNCTION(0x1234) or something,
> like the other built-in types do. If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.
That sounds the least scary behaviour: it may not do anything
particularly useful by default but at least it's obvious what's
happened. Having C<pick()> Huffman-encoded to nothing at all sounds
unnecessary for those that need it.
> Just a thought from someone vaguely in the Cozens Camp.
That, however, does sound scary -- I didn't know Simon had gone into the
holiday resort market. Is The Cozens Camp anything like Butlins?
Smylers
Luke Palmer
> From: Deborah Ariel Pickett <deb...@mail.csse.monash.edu.au>
> Date: Thu, 14 Nov 2002 09:05:16 +1100 (EST)
> Cc: perl6-l...@perl.org
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>
> Luke wrote:
> > When junctions collapse, is that reflected back in the original
> > junction, as it should be (QM-wise)?
> >
> > $foo = 1 | 2 | 4
> > print $foo;
> > # Foo is now just one of (1, 2, 4); i.e. not a junction
> > [...]
>
> Just a sanity check, but is this kind of behaviour something we still
> want from junctions? If we're trying to get away from the whole
> "Quantum Superposition" name, why do we want to still have an implicit
> collapse on $foo when it's used in certain contexts? To collapse like
> this doesn't make sense unless you're still thinking in quantum terms.
>
> Perhaps the above should just print JUNCTION(0x1234) or something, like
> the other built-in types do. If you really want to collapse the
> superposition, use an explicit collapse($foo) or observe($foo) or
> pick($foo) or whatever you want to call it.
You want these two subs to behave differently, then?
sub foo($x) {
if ($x != 4) {
print "Not four\n";
}
if ($x == 4) {
print "Four\n";
}
}
sub oof($x) {
if ($x != 4) {
print "Not four\n";
}
else {
print "Four\n";
}
}
If given 3 | 4, foo would print "Not Four\nFour\n", while oof would
print "Not four\n".
It seems that collapsation on examination is somewhat essential to
logical flow, when substituting a junction for a solid value. A piece
of code could certainly "be ready" for junctions (using C<grep> and
C<states>), but if not, very obscure bugs could surface (like this
one) when a junction is trying to behave like a real value.
I don't know how much this would come up in practice, but I do see it
as an issue. The question is: are junctions more useful if they do
or don't collapse upon examination?
Luke
Brent Dax
# sub foo($x) {
# if ($x != 4) {
# print "Not four\n";
# }
# if ($x == 4) {
# print "Four\n";
# }
# }
# sub oof($x) {
# if ($x != 4) {
# print "Not four\n";
# }
# else {
# print "Four\n";
# }
# }
More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).
# I don't know how much this would come up in practice, but I
# do see it as an issue. The question is: are junctions more
# useful if they do or don't collapse upon examination?
Actually, this suggests to me a flaw in the != operator, not a flaw in
junctions. We should probably make != exactly equivalent to the
negation of ==; this implies that when != gets a junction the type of
junction is reversed (any becomes all, all becomes any). This is much
scarier than it sounds--it's a lot like the !(x || y) == (!x && !y)
rule.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Damian Conway
> When junctions collapse,
Sigh, not another one of those dreadful reality TV shows:
When animals attack
When drivers collide
When junctions collapse
Next we'll get:
When mailing lists explode
When threads perpetuate
When Piers summarize
When Larrys make puns
;-)
> is that reflected back in the original junction,
No.
> as it should be (QM-wise)?
Except, of course, junctions aren't QM (hence the name change).
They're inspired by, but not slavishly constrained by, the laws of Physics. ;-)
> $foo = 1 | 2 | 4
> print $foo;
> # Foo is now just one of (1, 2, 4); i.e. not a junction
Nope. $foo is still a conjunction.
BTW, it's likely that printing $foo *won't* just randomly select one state;
that it will call $foo.serialize and print whatever string that (standard)
method returns. To get the select one at random behaviour, you need'll:
print $foo.pick;
> If so, what is perl going to do about the computationally expensive
> entanglement thingy?
Nothing. Unless Alex ports his Quantum::Entanglement module.
> $x = 0 | 1;
> $y = 0 | 1;
> $z = $x * $y;
>
> print $z; # 0 with 0.75 probability and 1 with 0.25
No. This probably just prints "0 1".
> # If 0 was printed, then $x | $y == 0
> # If 1 was printed, then $x & $y == 1
BTW, isn't that a seductive notation. ;-)
> Here, are $x and $y collapsed yet, or are they still in an entangled
> superposition?
Neither. They're still two completely independent junctions.
Damian
Piers Cawley
> Luke Palmer asked:
>
>> When junctions collapse,
>
> Sigh, not another one of those dreadful reality TV shows:
>
> When animals attack
> When drivers collide
> When junctions collapse
>
> Next we'll get:
>
> When mailing lists explode
> When threads perpetuate
> When Piers summarize
> When Larrys make puns
>
> ;-)
Designing programming languages for prisoners the Conway?
Not exactly short and snappy, but the best I could do at short notice.
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Damian Conway
>Luke wrote:
>
>
>> $foo = 1 | 2 | 4
>> print $foo;
>> # Foo is now just one of (1, 2, 4); i.e. not a junction
>
>Just a sanity check, but is this kind of behaviour something we still
>want from junctions?
>
>Perhaps the above should just print JUNCTION(0x1234) or something,
>like the other built-in types do.
But in Perl 6, they *don't*. The serialize somehow (probably by calling
their C<.serialize> method).
And I suspect that junctiosn serialize as follows:
* Disjunctions (C<any>s) serialize to their eigenstates.
* Conjunctions (C<all>s) and abjunctions (C<one>s)
with exactly one eigenstate serialize to that.
* Every other junction serializes to some representation of
its junctive type and internal states (e.g. "all(1,2)",
"none('Crosby', 'Stills', 'Nash', 'Young')", etc.)
Damian
Damian Conway
> sub foo($x) {
> if ($x != 4) {
> print "Not four\n";
> }
> if ($x == 4) {
> print "Four\n";
> }
> }
> sub oof($x) {
> if ($x != 4) {
> print "Not four\n";
> }
> else {
> print "Four\n";
> }
> }
>
> If given 3 | 4, foo would print "Not Four\nFour\n", while oof would
> print "Not four\n".
Maybe not. We're still pondering the interactions of subroutines and
junctive arguments. There are two possibilities (naturally ;-):
1. Passing a junction as a subroutine argument calls the
subroutine (in parallel, perhaps in separate threads)
with each value of the junction, then juncts the results
(in which case both C<foo> and C<oof> print both strings).
2. Junctions are just passed in as any other scalar argument.
(in which case what Luke suggested is correct).
The reason that 1) might be a better semantics is that it makes
something like:
sub longest_common_substr($a, $b) {
my $substrs_a = substr $a, any(0,$a.end), any(0,$a.length);
my $substrs_b = substr $a, any(0,$a.end), any(0,$a.length);
my $common = $substrs_a == $substrs_b;
return $common >= any($common.states);
}
work correctly.
That is, we generally want C<f($a|$b|$c)> to produce C<f($a)|f($b)|f($c)>.
In those cases where the junction *should* be passed into the subroutine
(primarilyboolean predicates, I suspect), that would have to be marked
explicitly:
sub even ($x is junctive) { # Allow C<even> to work on junctions too
return $x % 2 == 0;
}
Note that C<even> would work for regular scalars too, since they can be
considered a degenerate case of a disjunction (or of a conjunction or
abjunction, for that matter).
> I don't know how much this would come up in practice, but I do see it
> as an issue. The question is: are junctions more useful if they do
> or don't collapse upon examination?
I'm fairly solidly convinced that it's better if they don't.
Damian
Damian Conway
> More simply, !($x == 4) is no longer exactly equivalent to ($x != 4).
Correct. Junctive algebra and logic is slightly different. yet another
reason not to allow junctions to seep into subroutines by default.
> Actually, this suggests to me a flaw in the != operator, not a flaw in
> junctions. We should probably make != exactly equivalent to the
> negation of ==; this implies that when != gets a junction the type of
> junction is reversed (any becomes all, all becomes any).
I don't think so. I think it's important to preserve the useful
intuitive distinction between:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$larry&$curly != $hurt {...} # none hurt
Damian
David Wheeler
> if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
>
> and:
>
> if $moe|$larry|$curly != $hurt {...} # at least one not hurt
>
>
> and also between:
>
> if $moe&$larry&$curly == $hurt {...} # all hurt
>
> and:
>
> if $moe&$larry&$curly != $hurt {...} # none hurt
Although I admit I don't mind the lack of space on either side of the
C<|> operator, it bugs me with the C<&> operator. Couldn't C<&$larry>
in the above snippet dereference a code reference? I really hope that,
stylistically, we'll more often see code like this:
if $damian | $larry | $dan == $hurt {...} # i.e. any of them hurt
if $damian & $larry & $dan == $hurt {...} # all hurt
Regards,
David
--
David Wheeler AIM: dwTheory
da...@wheeler.net ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: The...@jabber.org