Damian Conway wrote:
> > 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).
>
> The Perl documentation contains only a second approximation to Perl. :-)
>
> The perl interpreter contains the first approximation.
> (For those who are wondering: Larry's brain contains the zero'th approximation)
Interesting comment, but between the documentation and trying things, we discover
what Perl is. Sometimes we could achieve different understandings of the behaviors
and intentions.
> > So I'm curious where you get this from,
>
> >From the fact that => currently converts any bareword left operand to a string.
Thanks for the clarification in your intentions, but isn't _any_ bareword is
converted to a string, unless it is in some particular context where a bareword is
meaningful (such as filehandle)? So that seems to be nothing unique to =>. You
could just as well say
bareword, $whatever
and get the same effect in perl5!
> Sure they do. p52p6 would handle the change in semantics by mapping
> every Perl 5 instance of:
>
> bareword => $whatever
> to:
> 'bareword', $whatever
>
> and every remaining instance:
>
> $non_bareword => $whatever
> to:
> $non_bareword, $whatever
So p52p6 could preserve the semantics, but running your favorite script through
p52p6 would remove all the places that you carefully used => in a meaningful (and
compatible with p6) manner, as well as those that are incompatible... forcing the
scriptor to change them back to do further maintenance... Workable, but clumsy.
So really the gist of your proposal is to coopt the => operator to have a new
meaning in perl6, that can be used in some but not all of the same contexts as it is
currently used in perl5, by rewriting the perl5 scripts to use the synonym , but
simultaneously preventing its use in perl6 in some of the common contexts in which
it is used in perl5.
> > 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 they're wrong. :-)
> The variables *shouldn't* appear in the calling scope, only their *names*.
I would agree here, except the following thought occurs to me:
sub trick_damian ( $foo, @foo ) { ... }
Perhaps you'll say that pairs only support scalar args anyway, so there is no
ambiguity with
& trick_damian ( 23, foo => 45, 99 );
that clearly @foo = ( 23, 99 ) ... but while perhaps it is OK that pairs support
only scalars, it probably isn't a good idea to prevent named arrays and hashes from
being passed to subs. So maybe pairs aren't a good solution for named parameters
for that reason... you're remaining comments only work for passing references to
hashes and arrays, not the hashes and arrays by value, as far as I can tell.
> > and pairs neither help that, nor provide help for passing
> > arrays or hashes by name.
>
> This can be correctly handled. The named parameter's context specifier
> would be propagated to the right operand of the =>. So:
>
> sub demo ( $name, \%options ) {...}
>
> will accept:
>
> demo(options=>%myopts, name=>'my name');
>
> because the C<\%> prototype for the parameter <\%options> will be
> propagated to the right operand of C<options=>%myopts>, causing it
> to act like C<options=>\%myopts>.
>
> Damian
--
Glenn
=====
There are two kinds of people, those
who finish what they start, and so
on... -- Robert Byrne
_______________________________________________
Why pay for something you could get for free?
NetZero provides FREE Internet Access and Email
http://www.netzero.net/download/index.html
