On Wed, 16 Feb 2005 09:18:42 -0600, [EMAIL PROTECTED] (Patrick R. Michaud)
wrote:
> On Wed, Feb 16, 2005 at 01:06:22PM +0000, Nigel Sandever wrote:
> >
> > Any chance that you could provide one or two simple but realistic examples
of
> > using Junctions and their operators?
>
> I'll give it a shot, but keep in mind that I'm somewhat new to this
> also. :-)
>
> First, junctions are an easy way to represent the relationships
> "any", "all", "one", or "none". So, where we once had to say:
>
> if ($x==$a or $x==$b or $x==$c or $x==$d) { ... }
>
> we can now say
>
> if $x == any($a, $b, $c, $d) { ... }
>
> Similarly, where we once had to say
>
> if (grep { $x == $^z } @list) { ... }
> if (grep { $x == $^z } @list) == 0 { ... }
>
>
> we can now say
>
> if $x == any(@list) { ... }
> if $x == none(@list) { ... }
>
I'd write the P5 none() case as
if ( grep { $x != $_ } @list ) { ... }
or
unless( grep{ $x == $_ } @list ) { ... }
which tends to reduce the sugaryness of the new syntax slightly.
> And for fun, try writing the equivalent of
>
> if $x == one($a, $b, $c, $d) { ... }
I'm also not entirely sure at this point whether that means
if( grep( { $x == $_ } $a, $b, $c, $d ) == 1 ) { ... }
or something different?
>
> without a junction. (Okay, one can cheat with C<grep>.)
>
But most of those examples pretty clear and understandable. I'm not sure that I
see their convenience alone as a convincing arguement for the existance of
Junctions. I keep thinking that there is something altogether more
fundementally
useful and ...well... cleverer underlying their inclusion, but at this stage I
am not seeing it.
In this usage, they appear to be replicating functionality that is already
being
provided via the inclusion of the hyper-operators.
('scuse me if I skip the unicode and/or get the syntax wrong!)
if( $x ==<< @list ) { ... } ## any?
if( $x !=<< @list ) { ... } ## none?
if( ( $x ==<< @list ) == 1 ) { ... } ## one?
if( ( $x ==<< @list ) == @list ) { ... } ## all?
It would very much depend upon what a hyper operator returns in a boolean
context, but they /could/ be made to work as I've indicated I think.
If the hyper operator returned one boolean result for each comparison it made,
and if a list of boolean values in a boolean context collapsed to a count of
the
trues/1s it contained, I think those would work. You would also get the bonus of
if( ( $x ==<< @list ) == 2 ) { ... } ## two() ( three(), ten() etc. )
if( ( $x <=<< @list ) == @list/2 ) { ... } ## fify percent below...
But I think the promise of Junctions appears to come from using them in
conjunction with each other.
$x = any( @list1 );
$y = all( @list2 );
$z = none( @list3 );
if( $x <= $y ) { ... }
if( any( $x != $y ) or all( $y == $z ) ) { ... }
except that I haven't got a clue what those mean?
I've sat and starred at the worked examples given elsewhere in this and the
other thread, and whilst I can follow how the results are derived when someone
lays them out for me--though I fell into the trap of accepting the one where
Damian made a mistake, which probably means I wasn't paying close enough
attention--when I get to the the last line and see that the answer it true (or
false), I look back at the original unexpanded statement and think:
Yes! But what does it mean? When and where is that going to be useful?
>
> A programmer can easily use these without having to worry about the
> notions of "autothreading" or "superpositions" or the like, and
> their translations to English are fairly obvious. I suspect that
> constructs like the above will be the majority of use for junctions.
>
> Things start to get "weirder" when we start storing junctions into
> variables, and/or passing those variables/junctions into subroutines.
> But I think this is not *too* far removed from the idea of placing a
> subroutine or a rule into a scalar -- i.e., using a scalar to represent
> something more than a single-valued primitive type. Thus, just as one
> can write
>
> $x = new CGI;
> $y = rule { \d+ };
> $z = sub { ... };
>
> and then use $x, $y, and $z later on for an object, rule, and sub
> (which may have a variety of side-effects associated with them), it makes
> sense that one can write
>
> $w = any(@list);
>
> and then use $w to refer to the junction later. And a programmer who
> does this is taking on some responsibility for understanding that $w
> isn't one of the "trivial" scalars anymore (same as for $x, $y, and $z).
>
> However, one difference is that when one typically uses an object, rule,
> or subroutine in a scalar there is some syntax that makes their nature
> apparent. Some feel that Junctions might be just a bit "too magical"
> in this respect (e.g., Luke has made some syntactic suggestions to try
> make the existence/threading of a junction more apparent).
>
I see the dangers of scalars that aren't oridinary scalars--I also accept your
premise that Junctions are no different from references in that regard. At this
stage my "big question" is:
What are they going to do for me?
And whilst the simple examples show some syntatic sugaryness, I think that it
will not be until I begin to see how to apply the more complex cases to real-
world problems that I could reach a conclusion about whether the value of their
inclusion outweights the onus of awareness the impose upon the programmer.
>
> Pm
Regards. njs.
