On Wed, Feb 16, 2005 at 06:04:37PM +0000, Nigel Sandever wrote:
> On Wed, 16 Feb 2005 09:18:42 -0600, [EMAIL PROTECTED] (Patrick R. Michaud)
> wrote:
> > And for fun, try writing the equivalent of
> > if $x == one($a, $b, $c, $d) { ... }
> > without a junction. (Okay, one can cheat with C<grep>.)
>
> I'm also not entirely sure at this point whether that means
> if( grep( { $x == $_ } $a, $b, $c, $d ) == 1 ) { ... }
> or something different?
Yes, that's essentially correct.
> 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?
Ouch, this makes my head hurt. :-)
A syntax note -- C<==> is an infix operator, thus the correct
syntax would have to be
> if( $x >>==<< @list ) { ... } ## any?
> if( $x >>!=<< @list ) { ... } ## none?
and the result of $x >>==<< @list would end up being a list of
true/false values.
> 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.
Part of the problem is that we don't have a "list of boolean values"
that is somehow distinguishable from "list of values". (And a list
evaluated in boolean context is true if the list is non-empty.)
If we create a "list of boolean values" type, it effectively becomes
a junction. :-)
> 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?
Well,
if ($x <= $y) { ... }
is better written out as:
if ( any(@list1) <= all(@list2) ) { ... }
which reads "if any of the elements of list1 are less than or equal to
all of the elements of list2". One could arguably claim/show that this
is mathematically equivalent to
if ( min(@list1) <= min(@list2) ) { ... }
except that junctions could potentially work with relationships that
aren't transitive as C<< <= >> is.
I'll have to think about your second C<if> statement a bit -- I agree
that it's not immediately obvious what it means, but I'm not sure that
we could come up with an alternate way of writing it which is also
immediately obvious. Phrased another way -- regardless of the
construct being discussed we can probably write an expression using
that construct that isn't easily deciphered at first.
> I've sat and starred at the worked examples given elsewhere in this
> and the other thread, and [...] 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?
Part of the reason for this may simply be that many of the examples
discussed in these threads are in fact "edge cases" that have been
designed to illustrate a point rather than to be useful. Indeed,
they're discussed simply because they aren't obvious.
> 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.
I think one can make this observation for many features slated for
Perl 6 -- i.e., the simple cases look simple but the full application
of complex cases isn't always immediately obvious. I know I get this
feeling from looking at things like roles, mixins, slurpy arrays,
slurpy hashes, C<temp> declarations, hypotheticals, hyperoperators, etc.
However, just as I don't have to be aware of every CPAN module that
exists in order to write Perl programs, I don't think having these
features built into the language will require a great deal of
awareness on the programmer until the programmer chooses to use them.
Others could reasonably disagree with this statement. And to
anticipate the followup question of "Well, why not make features such
as junctions into optional modules?", I think a partial answer is that
features like these really need deep language support to work
effectively in their complex applications. Otherwise we'd just
stick with Perl 5. :-)
Pm
