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.

Reply via email to