Do junctions support determining interesections of lists
Joshua Gatcomb
junctions.
Specifically, the ability to find the intersection, union, etc of a list.
my $matches = any( @x_chars ) eq any( @y_chars );
my $match = $matches.pick;
all( any() eq any() );
Patrick Michaud offered an infix myeq to let the problem be solved in user
space
as junctions at that time did not support what I wanted to do.
Today I examined the Synopses and found a couple of intriguing things:
In Synopsis 3:
"A junction is a single value that is equivalent to multiple values."
And then later on...
"Junctions are specifically unordered. So if you say
for all(@foo) {...}
it indicates to the compiler that there is no coupling between loop
iterations and they can be run in any order or even in parallel."
This implies to me that it is possible to get the values out of a junction
without calling a .values method if used in list context.
From Synopsis 12:
"To hyperoperate over the values of a junction you have to explicitly pull
out the values:
$junction.values».meth(@args);"
This implies to me that you can still get at the values by explicitly using
.values.
From Synopsis 9:
"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."
Ok, so what about a context expecting a junction of values as I think all(
any() eq any() ) is expecting?
My question today is 2 fold.
1. Where in the synopses would I find the various methods that can be
performed on a junction?
A. .values
B. .pick
C. ???
2. Do the junctions of today support finding the union, intersection, etc
without creating your own infix operator?
Cheers,
Joshua Gatcomb
a.k.a. Limbic~Region
Larry Wall
: Almost a year ago (2005-04-27), I wrote the list asking a question about
: junctions.
: Specifically, the ability to find the intersection, union, etc of a list.
Junctions are not intended for that use. We have Sets for that now.
Junctions are specifically intended to be sets with lazy booleans
properties, and those lazy boolean properties interfere with ordinary
set semantics.
: my $matches = any( @x_chars ) eq any( @y_chars );
: my $match = $matches.pick;
:
: all( any() eq any() );
Junctions use sets to do their calculations, and you can pull out the
set that a particular junction is using, but junctions are primarily
intended to tell you "whether", not "what". And a junction is specifcally
not a set, but a set of sets.
: Patrick Michaud offered an infix myeq to let the problem be solved in user
: space
: as junctions at that time did not support what I wanted to do.
:
: Today I examined the Synopses and found a couple of intriguing things:
:
: In Synopsis 3:
:
: "A junction is a single value that is equivalent to multiple values."
:
: And then later on...
:
: "Junctions are specifically unordered. So if you say
:
: for all(@foo) {...}
:
: it indicates to the compiler that there is no coupling between loop
: iterations and they can be run in any order or even in parallel."
:
: This implies to me that it is possible to get the values out of a junction
: without calling a .values method if used in list context.
That is not what is intended there. I believe that particular "for"
is autothreading, not extracting the values. Admittedly the text is not
clearly written. To each iteration it appears that there is only one
loop value, not a list. For autothreading in general, if the compiler
is able to falsify any of the variants, it doesn't need to run that
particular autothread at all, even if it would produce side effects.
: >From Synopsis 12:
:
: "To hyperoperate over the values of a junction you have to explicitly pull
: out the values:
:
: $junction.values».meth(@args);"
:
: This implies to me that you can still get at the values by explicitly using
: .values.
Yes, but you're really extracting the internal set of the junction
while throwing away the extra information that makes the junction
not a set. If you want to extract the set from a junction, you can
probably just use a coercion
$set = $junction as Set;
And in fact, merely using one of the set operators probably coerces its
arguments to sets, so you can probably say things like
any(@foo) (+) any(@bar)
which won't be treated any differently from
@foo (+) @bar
I expect the compiler could just optimize away any() there as noise,
and maybe all() too. Probably one() or none() though, since one() is
perhaps really a set of sets, while none() is a universal negative, which
is difficult to find the enumaration of.
But in particular, we'd like to be able to talk about sets of types
as Dog|Cat and have the internals autocoerce to Sets of type signatures
where junctions make little sense.
: >From Synopsis 9:
:
: "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."
:
: Ok, so what about a context expecting a junction of values as I think all(
: any() eq any() ) is expecting?
I don't think you can do simple set theory that way. Better to use
explicit sets. The junctional stuff is really about sets of sets,
and we'd be better off keeping a clean separation. Consider that
the set of sets:
one(@foo)
is a proper subset of the
any(@foo)
set of sets. Junctions are just convenient way to represent simple
sets of sets with a single set plus an extra dab of info.
: My question today is 2 fold.
:
: 1. Where in the synopses would I find the various methods that can be
: performed on a junction?
: A. .values
: B. .pick
: C. ???
I think .values and .pick are probably just Set operations, and if they
work on junctions, it'd be by autocoercion.
: 2. Do the junctions of today support finding the union, intersection, etc
: without creating your own infix operator?
The cabal already decided once (in Portland, I believe) to include the
standard set operators and a Set type, as well as ASCII representations
like (*) and (+) for the set ops so we don't force anyone to use
Unicode prematurely. Unfortunately these have not found their way
into the synopses yet, as far as I know.
Sorry if this is a bit meandering--jet lag is interfering
constructively with my native dimwit...
Larry
Larry Wall
a mistake to autocoerce junctions to sets by swiping their internal set
of values. Arguably any(1,2,3) should coerce not to
(1,2,3)
but to
(
(1),
(2),
(3),
(1,2),
(1,3),
(2,3),
(1,2,3),
)
Larry
Joshua Gatcomb
>
> On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
>
Junctions are not intended for that use. We have Sets for that now.
Ok. So this will work out of the box if you use the right tool. Cool.
The cabal already decided once (in Portland, I believe) to include the
> standard set operators and a Set type, as well as ASCII representations
> like (*) and (+) for the set ops so we don't force anyone to use
> Unicode prematurely. Unfortunately these have not found their way
> into the synopses yet, as far as I know.
Fair enough. For the benefit of everyone following along at home - which of
the Synopses should we be following to see how Sets fit into Perl6?
Sorry if this is a bit meandering--jet lag is interfering
> constructively with my native dimwit...
No apology necessary. I don't understand everything but I don't need to. I
am happy trusting that smarter people than me are working on the problem.
Larry
>
Joshua Gatcomb
a.k.a. L~R
Luke Palmer
I don't follow. Why is that the representation of any(1,2,3)? Is
this a disjunctive normal form; i.e. is 2 < any(1,2,3) equivalent to
the test:
2 < 1
|| 2 < 2
|| 2 < 3
|| 2 < 1 && 2 < 2
|| ...
Or did you have something else in mind?
Luke
Flavio S. Glock
> I don't follow. Why is that the representation of any(1,2,3)? Is
> this a disjunctive normal form; i.e. is 2 < any(1,2,3) equivalent to
> the test:
>
> 2 < 1
> || 2 < 2
> || 2 < 3
> || 2 < 1 && 2 < 2
> || ...
2 < 1
| 2 < 2
| 2 < 3
which ends up being the same thing after simplification
- Flavio S. Glock