# More junctions

0 views

### Luke Palmer

Nov 13, 2002, 2:50:49 PM11/13/02
to perl6-l...@perl.org
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

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

Nov 13, 2002, 5:05:16 PM11/13/02
to perl6-l...@perl.org
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.

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

Nov 13, 2002, 5:14:26 PM11/13/02
to perl6-l...@perl.org
Deborah Ariel Pickett wrote:

> 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

Nov 13, 2002, 11:39:11 PM11/13/02
to deb...@mail.csse.monash.edu.au, perl6-l...@perl.org
> Mailing-List: contact perl6-lan...@perl.org; run by ezmlm
> 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

Nov 14, 2002, 12:10:38 AM11/14/02
to Luke Palmer, deb...@mail.csse.monash.edu.au, perl6-l...@perl.org
Luke Palmer:
# 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.

### Damian Conway

Nov 14, 2002, 7:55:57 PM11/14/02
to perl6-l...@perl.org

> 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 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

Nov 15, 2002, 2:05:21 AM11/15/02
to Damian Conway, perl6-l...@perl.org
Damian Conway <dam...@conway.org> writes:

>
>> 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 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

Nov 16, 2002, 4:50:56 PM11/16/02
to perl6-l...@perl.org
Deborah Ariel Pickett wrote:

>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

Nov 16, 2002, 7:15:55 PM11/16/02
to perl6-l...@perl.org
Luke Palmer wrote:

> 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

Nov 16, 2002, 7:52:42 PM11/16/02
to perl6-l...@perl.org
Brent Dax wrote:

> 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

Nov 16, 2002, 8:00:42 PM11/16/02
to Damian Conway, perl6-l...@perl.org
On Saturday, November 16, 2002, at 04:52 PM, Damian Conway wrote:

> 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