Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree with you, but Larry has repeatedly said that he wants
to view Junctions as lexical sugar rather than as a powerful programming
tool. So I'm thinking that we'll need to experiment with modules before
anything gets admitted to the core language.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
I think that the all{..} notation is a little too subtle, and somewhat
clumsy (what if there are "one" or "none" junctions in $d? do you want
to splat them all?).
The way I'd view this (before optimization) is:
my $p = (reverse 1..21).first: { $_ == [+] @p };
my $d = (reverse 1..21).first: { $_ == [+] @d };
if ! $p { say "player bust" }
elsif ! $d { say "dealer bust" }
elsif $p > $d { say "player wins" }
else { say "dealer wins" }
If this is the structure of the problem, the question then becomes how
to move from this brute force implementation to something more elegant
(analytical).
I discuss this on http://dave.whipp.name/sw/perl6/perl6_xmas_2008.html.
I've revised my ideas a little since then (by proposing a more general
grep metaoperator "G[op]" that has applicability beyond junctions) but
the basic concepts mesh with yours, I think.
