Thomas Sandlaà writes:
> Patrick R. Michaud wrote:
> >On Wed, Apr 27, 2005 at 08:46:53AM -0400, Joshua Gatcomb wrote:
> >
> >>The problem is that in the regex version I use capturing parens to
> >>identify the character matched. For the purposes of the problem I
> >>don't need to rely on the first character matched I just need to know
> >>1.
> >>
> >>Without doing a lot of research into junctions, I thought the
> >>following would work:
> >>
> >>my $matches = any( @x_chars ) eq any( @y_chars );
> >>my $match = $matches.pick;
> >
> >
> >Perhaps the easiest way to explain the difficulty here is to note that
> >executing a relational op (i.e. returning a boolean) value on a junction
> >argument returns a junction of boolean values.
>
> Is that so? Does Perl6 have some fundamental law of junction preservation?
> I would expect $matches to be either false or true---the junction values
> are garbage collected.
Nope, not unless we give comparitors special junctive semantics (which
may end up being a good idea). Consider:
my $match = any(<a b c>) eq any(<c d e>);
my $weird = $match + 1;
say "Ok" if $weird == 2;
This program does not say Ok if the junction "garbage collects" its
states.
Indeed, the junction doesn't preserve under boolean context.
my $match = ?(any(<a b c>) eq any(<c d e>));
# $match is now 1 or 0
Quantum::Superpositions made comparitors special.
my $match = any(<a b c>) eq 'b'; # $match is 'b'
There's something eerie and inconsistent about that, mostly that you
have to mark your functions as comparitors when you want them to do
that. But it is vastly less a pain in this case than having to write
Patrick's myeq.
The more I think about junctions, the less nice they seem to be. Not to
say that they don't kick ass still.
Luke
