On Tue, Apr 04, 2006 at 09:16:23AM -0400, Joshua Gatcomb wrote:
: 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
