Johan Vromans wrote:
>
> If a Perl construct does not suffer from a slight change that makes
> it easier to accept by new programmers, I think such changes should
> be seriously considered.
Yes; but the world if full of language [sorry, couldn't resist]
which is optimized (or at least meant to b
John Porter <[EMAIL PROTECTED]> writes:
> As someone else said before me, Perl should not be changed
> Just Because We Can. Aspects which have proven usefulness and
> are deeply engrained in the Perl mindset should not be tampered
> with just because some recent convert finds them un-Algol-like
Simon Cozens wrote:
> John Porter wrote:
> > But they are inextricably bound by perl's parsing rules.
>
> Perl 5's parsing rules. I don't think Perl 6 *has* a parser just yet.
As someone else said before me, Perl should not be changed
Just Because We Can. Aspects which have proven usefulness a
This just isn't making sense.
Currently one has to write
my( $x, $y, $z ) = @_;
And you're willing to eviscerate perl to save two keystrokes;
you say you'd be happy with either
my $x, $y, $z = @_;
or
( $x, $y, $z ) = @_;
but the (consequent) fact that
$x, $y,
On Fri, Feb 16, 2001 at 03:45:21PM -0500, John Porter wrote:
> But they are inextricably bound by perl's parsing rules.
Perl 5's parsing rules. I don't think Perl 6 *has* a parser just yet.
> You can't keep Perl6 Perl5.
See?
--
What happens if a big asteroid hits the Earth? Judging from real
Nathan Wiger wrote:
> To rehash, all this discussion should involve is the possibility of
> making "my" swallow its list args:
>my $x, $y, $z; # same as my($x, $y, $z)
> That's it. No changing the way lists and , and = work in Perl.
But they are inextricably bound by perl's parsing rules.
Nathan Wiger wrote:
>
> I wouldn't be so hasty to withdraw from the my binding argument. There's
> many uses of "my" that are required even with the "use scope" pragma (at
> least as I described it in RFC 64, but feel free to point it out if I
> missed an application). I think there's some good ch
>FOR
>---
> 1. It becomes more consistent with other Perl functions
my is not a function. It is a declaration. Functions take arguments
and return values. my does not. It is language construct like if.
Unless, of course, you claim that if is a function, too. That
ways lies LISP.
Branden wrote:
>
> As to the second item b), I would say I withdraw my complaints about `my' if
> my other proposal of `use scope' gets approved (since then I don't need `my'
> anymore!). I guess I would be happier with `use scope', and I also think it
> would make you happier, since it wouldn't
