Perl6 RFC Librarian wrote:
> The => operator would cease to be a
> first-argument-stringifying comma operator
I find nothing in the documentation that suggests that => is anything other than a
plain comma operator, yet you call it a "first-argument-stringifying comma
operator". In fact, the documentation explicitly claims "=>" is a synonym of ","
(see perldata).
So I'm curious where you get this from, and what you mean by it, and whether it is
relevant to this RFC.
> Note that these semantics still support the popular:
>
> sub hash_like_args {
> my %args = @_;
> # etc.
> }
>
> hash_like_args(serial_num=>1234, name=>'demo', rank=>'RFC');
But not the (safer) alternative:
sub hash_like_args {
my ( $name, $val );
while ( @_ >= 2 ) {
$name = shift;
$val = shift;
if ( $name eq 'serial_num' ) { ... }
elsif ( $name eq 'demo' ) { ... }
elsif ( $name eq 'rank' ) { ... }
else
}
}
> =head2 Pairs and multiway comparisons
>
> Pairs also provide a clean way of implementing multiway comparisons.
>
> It is proposed that when a pair is evaluated in a boolean context, it
> would evaluate to the truth value of its key. But when evaluated as the left
> operand of a comparison operator, it would evaluate to its value,
> I<but> would short-circuit if its key were false.
This is extremely strange, to say the least, but that's no reason not to do it.
While this technique does allow pairs to achieve multiway comparison based on
context tricks together with the above pair evaluation technique, it would require
rewriting every overloaded comparison operator to produce a pair, rather than a
boolean. Maybe p52p6 could handle most cases of this rewriting, but in general it
would be extremely hard. But it seems that the existing operators (and overloaded
functions) could continue to be used and achieve the same result, if the language
syntax were enhanced to directly support multiway comparisons. For an expression
such as
if (( e1 ) < ( e2 ) < ( e3) < ( e4 ))
the first two operands could be evaluated, saved in temporarys, passed to <, and
based on the pure boolean result, a choice could be made about continuing. If
false, the whole expression would be false. If true, e3 could be evaluated, and
the saved value of e2 and e3 passed to <, and proceed as before.
While your pairs certainly achieve the same logic flow, I don't see that this trick
is particularly beneficial... as it forces extra baggage (generation of the pair)
onto binary comparisons.
> RFC 25: Operators: Multiway comparisons
My comments in summary are:
With an appropriate prototyping system, perhaps pairs would be useful for named
scalar arguments to subs. Quite a few have complained about missing the $ in other
named parameter proposals though, and pairs neither help that, nor provide help for
passing arrays or hashes by name.
Using pairs for multiway comparisons could be an implementation technique, but
seems unnecessary and somewhat more incompatible than just changing the language
definition to support multiway comparison.
Perhaps pairs might even be useful for other things, but what? They _seem_ like
they could be useful, the syntax proposed doesn't seem too harmful, but I haven't
found a compelling benefit in this RFC.
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
____________NetZero Free Internet Access and Email_________
Download Now http://www.netzero.net/download/index.html
Request a CDROM 1-800-333-3633
___________________________________________________________
