develooper Front page | perl.perl6.language | Postings from March 2005

Re: Junctions - feedback and desires

Thread Previous | Thread Next
From:
Sam Vilain
Date:
March 10, 2005 14:12
Subject:
Re: Junctions - feedback and desires
Message ID:
4230C629.9070000@vilain.net
Rod Adams wrote:
> I do not believe that is possible.
> This is the "filtering" or "unification" behavior that people keep 
> wanting junctions to have, which they do not.

Aww!  But what about all the great problems that could be expressed
with them?  I know of two languages that consider this to be a core
feature now (Prolog, Oz[1]).

> A given junction always has all of the values it was made with. No more, 
> no less. If you want something else, you have to make a new junction. 
> Consider that it's been decided that :
> 
>    $j = 11|0;
>    10 < $j < 1
> 
> Is true. $j retains the 0 even after the 0 failed a test.

I can't see how this can be possible with the possibility of
autothreading as described in [2].  Maybe the example you suggest is
true, if both comparisons happen "simultaneously", but what about this
one?

if ($j < 10) {
     if ($j < 1) {
         say "$j took on two values at once";
     }
}

Let's say that the implementation chose to implement the first if() by
auto-threading.  The first thread where $j == 11 succeeds.  The second,
where $j == 1 fails.  In the second thread, $j == 11 fails.

It is by this assumption that the example in [3] was built.

But wait, isn't (10 < $j < 1) likely to produce the same opcode tree
as if($j<10){if($j<1){}} ?

 > As for the "current" value, there is only a current value during
 > threading.

Isn't the threading conceptual, and actual threading invoked only when
the optimiser has finished using available logic / set theory operations
to prevent absurd numbers of threads being made that exit immediately?

Sam.


References:

1. http://xrl.us/fehh (Link to www.mozart-oz.org)

    A representation of send+more=money in Oz

2. http://dev.perl.org/perl6/synopsis/S09.html

Some contexts, such as boolean contexts, have special rules for dealing
with junctions. In any scalar context not expecting a junction of values,
a junction produces automatic parallelization of the algorithm. In
particular, if a junction is used as an argument to any routine (operator,
closure, method, etc.), and the scalar parameter you are attempting to
bind the argument to is inconsistent with the Junction type, that
routine is "autothreaded", meaning the routine will be called
automatically as many times as necessary to process the individual scalar
elements of the junction in parallel.

3. An implementation of send+more=money using Perl 6 Junctions

    http://svn.openfoundry.org/pugs/examples/sendmoremoney.p6
    http://xrl.us/feis (revision at time of writing this message)


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About