> 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