> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Deborah Ariel Pickett <[EMAIL PROTECTED]>
> Date: Thu, 14 Nov 2002 09:05:16 +1100 (EST)
> Cc: [EMAIL PROTECTED]
> 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
