On Fri, 16 Feb 2001, Stephen P. Potter wrote:
> Lightning flashed, thunder crashed and "Branden" <[EMAIL PROTECTED]> whisp
> ered:
> | For the list managers: Could we have a list apart from -language, so that we
> | don't bother all with this `par'-issue ??? Please? Perhaps a list that
> | inclu
On Fri, Feb 16, 2001 at 06:33:46PM -0500, [EMAIL PROTECTED] wrote:
> On Fri, Feb 16, 2001 at 02:48:01PM -0800, Edward Peschko wrote:
> > 1) be lax on warnings and strict in a script, assume strictness and
> >warnings in the modules. Rationale: in a script, you really
> >ha
On Fri, Feb 16, 2001 at 02:48:01PM -0800, Edward Peschko wrote:
> 1) be lax on warnings and strict in a script, assume strictness and
>warnings in the modules. Rationale: in a script, you really
> have an audience of one. With few exceptions, you are only
>
On Fri, Feb 16, 2001 at 03:51:31PM -0500, [EMAIL PROTECTED] wrote:
> Can we take this thread over to perl6-language-strict? Its where it
> belongs. Then you can argue to your heart's content and let us know
> when you've reached a conclusion.
Ok, that seems fair enough. But I really don't think
On Fri, 16 Feb 2001, Stephen P. Potter wrote:
> How about a perl6-install list? This discussion really doesn't fit into
> any of the current top level lists, so we can make a new top level and
> cover other installation issues as well. Ask, can you make this, if the
> name is agreeable.
There
> Why with `my' I do need them? Why don't these behave the same?
Because the precedence is different.
Remember, 'my' is a lexical construct.
It does not "return" a value, and it does not
take "arguments" -- not in the runtime sense.
It applies only to literal variable symbols.
It is meaningless (
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,
Can we take this thread over to perl6-language-strict? Its where it
belongs. Then you can argue to your heart's content and let us know
when you've reached a conclusion.
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.
Lightning flashed, thunder crashed and "Branden" <[EMAIL PROTECTED]> whisp
ered:
| For the list managers: Could we have a list apart from -language, so that we
| don't bother all with this `par'-issue ??? Please? Perhaps a list that
| includes the issue on directory structure, and other issues re
Branden wrote:
> a) Many of us want Perl to have globals as default, what is opposed to
> some that want `use strict' and `-w' turned on by default.
You are profoundly confused.
Globals *are* the default in current perl; and having strict 'vars'
on does not magically change that.
strict 'subs',
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
Well, I'll try to reach to an agreement here, since this discussion is
getting pretty much pointless.
What do we know:
a) Many of us want Perl to have globals as default, what is opposed to some
that want `use strict' and `-w' turned on by default.
b) Some of us (that would be me, I think) think
John Porter wrote:
> > Well, for me, it isn't useful, unless you can show me I'm wrong. At
least
> > give me an example that shows it's more useful this way.
>
> First, we must always remember that whatever we do, we can
> force explicit precedence through the addition of parentheses.
> The cases
At 09:56 AM 2/16/2001 -0500, John Porter wrote:
> > As for the -q thing, I think it is far *less* of a burden to add "use
> > strict" and "use warnings" when you're writing a big piece of code. When
> > you're writing 5 lines, every extra character counts. When you're
> > writing 500 or 5000 lines
John Porter wrote:
> > Having `my' with the same precedence rules as `print' for example,
>
> 'my' is not 'print', it is not like 'print', is not comparable
> to 'print'. Please stop with the bogus comparisons.
>
Agree they're different (one is compile-time, other runtime, and much more
differe
Simon Cozens wrote:
>
> John, settle down. None of us profess to be fantastic language designers,
> which is why we gave Larry the job. That being done, I'm not entirely sure why
> people are continuing to argue about these things. :)
You're right, of course. I should have faith that Larry
will
On Fri, Feb 16, 2001 at 10:26:40AM -0500, John Porter wrote:
> Oh, that's a terrific improvement.
> Basically you want to change (= break) the current precedence
> of the comma operator. Thank you, Mr. Language Designer.
John, settle down. None of us profess to be fantastic language designers,
w
On Fri, Feb 16, 2001 at 01:20:43PM -0300, Branden wrote:
> `my' DWIMs.
`my' will do what *you* mean at the cost of every single existing perl
programmer that currently uses it to relearn what it means. Not a
good trade off IMHO.
I'd rather `my' does what *I* mean which is what it does now.
> I
Edward Peschko wrote:
> And don't dismiss 1 as trivial. I personally have spent hours
> tracking down simple bugs that I otherwise would have found
> within SECONDS with 'use strict'.
Which is why, after going through this twice, I now habitually
blow in 'use strict' without a moment's thought.
(
John Porter wrote:
> It turns
> out that 'my' having higher precedence than comma is signficantly
> more useful than if it had a lower precedence.
>
Well, for me, it isn't useful, unless you can show me I'm wrong. At least
give me an example that shows it's more useful this way.
> Let's all just
On Thu, 15 Feb 2001 10:04:51 -0300, Branden wrote:
>Why `do FILE' behaves like eval, if there's eval to do it? Isn't this a
>little too much not-orthogonal? Why don't we require `eval { do FILE }' to
>have the behaviour of not dying and setting $@ ?
The reason for its existence is simple: histor
[EMAIL PROTECTED] wrote:
>
> Even with warnings on, they are all too often ignored. Just today I
> got an email from a friend asking "why doesn't this program work"?
> The program was throwing a warning, but he'd ignored it. Turns out it
> was one of the problems. And he's no newbie.
Bizarre.
On Friday 16 February 2001 11:38, Branden wrote:
>
> (my($a),our($b),local($,),my($c)) = @_;
>
> What is it, anyway? A joke? (There's Perl poetry, why can't be there Perl
> jokes?) Who writes this kind of code anyway?
Okay, you caught me, it was a contrived exampled. The actual code was
On Friday 16 February 2001 11:20, Branden wrote:
> proposal. I don't think it works, because
>
> $a, $b, $c = @_;# $c gets 10 for @_=(1..10)
>
> mean a different thing that
>
> my $a, $b, $c = @_; # $c gets 3 for @_=(1..10)
It does?
>
> The last code should behave as
>
John Porter wrote:
> Come on. What's so hard about knowing
> ( $x, $y, $z )
> is a bunch of variables, and
> my( $x, $y, $z )
> is a bunch of variables declared local.
> Answer: nothing.
>
If you see some code saying
my $a, $b, $c;
Would you say $b and $c are subject to a different scoping
Edward Peschko wrote:
> NOTE: to perl5 users - by default, perl is doing more up-front error checking.
> To get the old behavior, you can say 'perl -q' in front of your scripts,
Yep; the perl manpage has said, since time immemorial, that
the fact that -w was not on by default is a BUG.
So chan
Branden wrote:
> Anyway, I don't see why `local' (and `our' and `my') should bind more
> strongly than , and = . They are list operators, they should behave
> the same as those.
"In general, perl does what you want -- unless what you want is
consistency." The point is that consistency is NOT the
Edward Peschko wrote:
> well, for the small fraction of people that use it, they probably are
> experienced and know to use parens to disambiguate.
No, *everyone* knows to use parens to disambiguate.
> And anyways:
> my $a, $b, $c = @_;
> not working is 'very hard to bugtrack and totally une
Bryan C. Warnock wrote:
> Oh, wait, commas are now implicitly parenthesized, so that
> (my $a, $b, $c) = @_;
> can be written as
> my $a, $b, $c = @_;
>
Oh! I never said commas are implicitly parenthesized! That was other
proposal. I don't think it works, because
$a, $b, $c = @_;# $
Nathan Wiger wrote:
> Let alone that this:
>my $x, $y, $z;
> Doesn't DWIM, again according to what most people think.
Come on. What's so hard about knowing
( $x, $y, $z )
is a bunch of variables, and
my( $x, $y, $z )
is a bunch of variables declared local.
Answer: nothing.
On Friday 16 February 2001 09:24, Branden wrote:
> I said:
> > Anyway, I don't see why `local' (and `our' and `my') should bind more
> > strongly than , and = .
Because the implicit global scope declarator binds that tightly.
Because you lose the ability to mix scope declarators in an assigment.
I said:
> Anyway, I don't see why `local' (and `our' and `my') should bind more
> strongly than , and = . They are list operators, they should behave the
same
> as those.
>
Actually, they *look like* list operators, they should behave like those.
> - Branden
>
>
Bryan C. Warnock wrote:
> On Friday 16 February 2001 07:36, Branden wrote:
> > But it surely isn't
> > consistent with the rest of the language.
>
> It's consistent with "our" and "local", which are really the only other
> things in the language that parallel its use.
>
Well, `local' is actually
<[EMAIL PROTECTED]> wrote:
> > tie (my $shoe) => $string;
>
> Not enough arguments for tie...
>
tie +(my $shoe) => $string;
This is the same as would happen to `print', for example. Or else, the
easyer
tie my($shoe) => $string;
It doesn't look like a function, so it isn't.
>
> Ah, mo
Edward Peschko wrote:
> How about 'an implicit parens around a set of statements separated by
commas
> in any context'? This is consistent
>
> $a, $b, $c = $d, $e, $f; # ($a, $b, $c) = ($d, $e, $f);
>
I guess this should be
$a, $b, ($c = $d), $e, $f
I think making `my' work just the same as
<[EMAIL PROTECTED]> wrote:
> @a = (1 .. 10);
> $a, $b, $c = @_;
>
> $c becomes 10. Should $c become 3 when my is placed before $a?
>
No. If my binds weaker than =, it would be
my $a, $b, $c = @_;
is the same as
my $a, $b, ($c = @_);
as the opposite of
(my $a, $b, $c) =
On Friday 16 February 2001 07:36, Branden wrote:
> But it surely isn't
> consistent with the rest of the language.
It's consistent with "our" and "local", which are really the only other
things in the language that parallel its use.
--
Bryan C. Warnock
bwarnock@(gtemail.net|capita.com)
<[EMAIL PROTECTED]> wrote:
> As I wrote elsewhere, other reasons not to change the behaviour of my:
>
> GetOptions (foo => \my $foo,
> bar => \my $bar);
>
GetOptions (foo => \my($foo),
bar => \my($bar));
> tie my $shoe => $tring;
>
tie my($shoe) => $tring;
#
On 15 Feb 2001, at 20:52, [EMAIL PROTECTED] wrote:
> On Thu, Feb 15, 2001 at 10:31:34AM -0300, Branden wrote:
> > With Perl 6, it will (probably) be possible to have values with boolean
> > value independent of integer or string values, so that it will be possible
> > to have a value that when vi
44 matches
Mail list logo
