Re: Auto-install (was autoloaded...)
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 > | includes the issue on directory structure, and other issues related to > | installation and deployment of Perl itself and Perl programs & modules. > > 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. [EMAIL PROTECTED] already exists. http:[EMAIL PROTECTED]/ - ask -- ask bjoern hansen - http://ask.netcetera.dk/
Re: Warnings, strict, and CPAN
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
> >have an audience of one. With few exceptions, you are only
> >running the script for yourself.
> >
> >With a *module* however, you should know better. Since you
> >are intending your code to work with the 'outside world', you
> >have a civic duty to make your interface clean. And if you
> >really know what you are doing, you can turn off the warnings,
> >strictness as you see fit.
>
> Its a fine rationale, but I'm very, very loathe to implicitly split
> Perl into two seperate languages based on what the filename is.
Why? Its not the filename, its how its used -
require("A"); # library - strict, warnings on
use A;# library - strict, warnings on
do "A"# library - strict, warnings on but who cares, do is
# hardly ever used.
eval("\$a = '1'");# code - strict off
The functionality for adding 'strict' and 'warnings' would be added onto use
and require. Just as require is a wrapper around do, and use is a wrapper around
require, the new use would be use + strict, warnings and so on. The only thing
that would change in perl6 is the contents of the wrappers.
> > 2) provide a flag (-W ) which is a combo of 'use strict' and
> > 'use warn' for scripts. Perhaps the -W should have warning
> > levels ie - '-W1' means just warn, '-W2' == warn + strict,
> > etc etc etc.;
>
> It doesn't make much sense to make 'strict' an easy command line flag.
> strict is something you want on either all the time or not at all
> (with regards to a single program).
Well, its the converse of '-q'. If people are too damn lazy to type '-q' and
get what they want, well hell, I'll just have to type '-W'. And its less typing
than '-w -Mstrict' or 'use strict; use warnings;'
Ed
Re: Warnings, strict, and CPAN
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 >running the script for yourself. > > With a *module* however, you should know better. Since you >are intending your code to work with the 'outside world', you >have a civic duty to make your interface clean. And if you >really know what you are doing, you can turn off the warnings, >strictness as you see fit. Its a fine rationale, but I'm very, very loathe to implicitly split Perl into two seperate languages based on what the filename is. > 2) provide a flag (-W ) which is a combo of 'use strict' and > 'use warn' for scripts. Perhaps the -W should have warning > levels ie - '-W1' means just warn, '-W2' == warn + strict, > etc etc etc.; It doesn't make much sense to make 'strict' an easy command line flag. strict is something you want on either all the time or not at all (with regards to a single program). Of course, you'd want to have "perl -l -Wall" ;)
Re: Go to perl6-language-strict please (was Re: Warnings, strict, and CPAN)
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 that it should be a religious issue - there are tons of places where a consensus can be reached. I think we could even modify RFC 16 so that everybody is satisfied. Here are a couple more ideas: 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 running the script for yourself. With a *module* however, you should know better. Since you are intending your code to work with the 'outside world', you have a civic duty to make your interface clean. And if you really know what you are doing, you can turn off the warnings, strictness as you see fit. 2) provide a flag (-W ) which is a combo of 'use strict' and 'use warn' for scripts. Perhaps the -W should have warning levels ie - '-W1' means just warn, '-W2' == warn + strict, etc etc etc.; Ed
Re: Auto-install (was autoloaded...)
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 already is a perl6-build list. Perhaps you can just use that? -- Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
> 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 (and illegal) to write my(6) or my(foo($x)). You're telling the compiler something about the variable. In effect, you're placing a TAG on the variable. In p6 attribute terminology, you could think of it as something like $x:lexical, $y:lexical, $z:lexical Such tags, or attributes, don't naturally distribute. And it doesn't make much sense (to me, at least) to make such a declaration maximally distributive, instead of minimally distributive as it is now. -- John Porter
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
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 and are deeply engrained in the Perl mindset should not be tampered with just because some recent convert finds them un-Algol-like. -- John Porter
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
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, $z = @_; could not possibly be unbroken (wrt DWIM) doesn't faze you. !!! Branden wrote: > Changing `,' and `=' has too much side effects to be considered. And because they're all bound up together, changing 'my' is also beyond consideration. > 1. `my' becomes more consistent with other Perl thingys > that get lists as arguments, as Perl functions, for > example. 'my' is a declarative operator whose effects are distributive. That's useful. Let's not break it. > Well, the workaround is so simple, just put parenthesis around. As someone has already said, you seem to be willing to make an arbitrary change that just shifts around where parens are needed, for no real gain. All else being equal, perl should not be changed. > Only what will break is the using of my in the middle of the > arglist of a function, basically. That's a gross oversimplification; anywhere you can put a variable, you can declare it with 'my' (except, of course, in string interpolations). > And that's easily translatable by putting parenthesis > around `my's variables, what also increases readability. If you're willing to require additional parens from other programmers, you should be wiling to bear the burden of putting them in, yourself. -- John Porter
Go to perl6-language-strict please (was Re: Warnings, strict, and CPAN)
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.
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
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 realistic simulations involving a sledge hammer and a common laboratory frog, we can assume it will be pretty bad. - Dave Barry
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
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. You can't just change 'my's precedence and expect ",", "=", etc. to be unaffected. > If you want to use split you still have to say: >my($name, $passwd) = split ':'; Special-casing this is unacceptable. >FOR > 1. It becomes more consistent with other Perl functions AGAINST: Consistency with functions (not "other" functions) is not a goal. > 2. It makes certain uses easier to write and understand, > such as when declaring lots of variables on the same > line. Many expect this: > my $x, $y, $z; > to DWIM. AGAINST: WYM is apparently not what most perl programmers mean. -- John Porter You can't keep Perl6 Perl5.
Re: Auto-install (was autoloaded...)
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 related to | installation and deployment of Perl itself and Perl programs & modules. 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. -spp
Re: Closures and default lexical-scope for subs
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', strict 'refs', and -w have no bearing on any of this, of course. > Why don't we ship Perl 6 with two different binaries? Even better, perl6 will be much more easily hackable (by design) than perl5 is, so we should able to try making these modifications ourselves. Also, you'll be able to install policy-specific binaries at your own sites. > 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!). Don't hold your breath. (All this to save two keystrokes. Sheesh.) > In Perl 6, where the compiler will be written in Perl, What have you been smoking? -- John Porter You can't keep Perl6 Perl5.
Re: The binding of "my" (Re: Closures and default lexical-scope for 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 chugging on the my > binding concept going on, so let's not kill it quite yet. > OK. I'll keep discussing it, although I'm now positioning me FOR `use scope' as I described in my last postings, which is a little different than what's proposed on RFC 64 and doesn't suffer of some of the AAAD that RFC 64 (ie. `our' outside the scope may change the scope of a variable in a distant block). You're actually right saying that even with `scope', `my' would be useful in some circumstances, but as it would be less situations, I don't mind if it keeps how it is, I probably won't use it too much to bother changing it. > 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. If you > want to use split you still have to say: > >my($name, $passwd) = split ':'; > Well said! No changing `,' and `=', only `my' (and possibly `local' and `our'). Changing `,' and `=' has too much side effects to be considered. >FOR >--- > 1. It becomes more consistent with other Perl functions > Jarkko Hietaniemi wrote: > 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. I actually like LISP, but why reinvent it...? Well, let's rephase it: 1. `my' becomes more consistent with other Perl thingys that get lists as arguments, as Perl functions, for example. >AGAINST >--- > > 2. In certain situations, such as trying to declare a variable > inline as a list arg, it requires an extra set of ()'s. > For example: > > tie my $shoe, $string; > > no longer works as written, since my will gobble the vars > and tie will complain "not enough arguments". > > Once point of consideration: What if my() returned its > argument list verbatim, similar to how bless() does > double-duty? > Actually, that code above returns two arguments, like tie my($shoe, $string); which is the same as my $shoe; my $string; tie $shoe, $string; But that's different of what it (probably) should be: tie my($shoe), $string; Well, the workaround is so simple, just put parenthesis around. It's the same as what you'd do if you were using the result of a function as parameters to another function, so it means (even knowing that `my' isn't a function) consistency with other Perl thingys. > 3. This is a change which will break existing Perl code. > It's good to say: Not always. my( $x, $y, $z ) won't break. So won't my $x = $y;. Only what will break is the using of my in the middle of the arglist of a function, basically. And that's easily translatable by putting parenthesis around `my's variables, what also increases readability. Think about it, the change isn't really big. The only differences are the necessary parenthesis on usage of `my' in the middle of a list of arguments and the fact of `my $a, $b, $c;' DWIMs, what is a big win, IMHO. Beginners would know they can use `my' the same way they use every function in Perl, what also makes Perl a little easier to use. (Note I didn't say `every *other* function', I *know* `my' isn't one.) - Branden
Re: The binding of "my" (Re: Closures and default lexical-scope for subs)
>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. I actually like LISP, but why reinvent it...? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
The binding of "my" (Re: Closures and default lexical-scope for subs)
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 bother the current way `my' works, > and all you'd have to do is not bothering the `scope' pragma exists. 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 chugging on the my binding concept going on, so let's not kill it quite yet. 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. If you want to use split you still have to say: my($name, $passwd) = split ':'; As far as I can tell, these are the current arguments for/against my being changed to bind less tightly: FOR --- 1. It becomes more consistent with other Perl functions 2. It makes certain uses easier to write and understand, such as when declaring lots of variables on the same line. Many expect this: my $x, $y, $z; to DWIM. AGAINST --- 1. This is a change that will make mixing type declarations in the same line of code harder to do, such as: (my $x, our $y) = @_; 2. In certain situations, such as trying to declare a variable inline as a list arg, it requires an extra set of ()'s. For example: tie my $shoe, $string; no longer works as written, since my will gobble the vars and tie will complain "not enough arguments". Once point of consideration: What if my() returned its argument list verbatim, similar to how bless() does double-duty? 3. This is a change which will break existing Perl code. Although overall I support the "FOR" (I think?), those are some pretty big "AGAINST" arguments that we need to consider. -Nate
Re: Closures and default lexical-scope for subs
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 that `my' doesn't DWIM, while most think `my' is OK the way it is now. Well, for item a), I have a proposal. Why don't we ship Perl 6 with two different binaries? Like `perl' and `pqd' (perl-quick-and-dirty) or `p6' or anything like that? One would have strict & warnings on by default, while the other (whose name is shorter and would therefore save some typing) could still be used for q&d scripts and one-liners? That would also make unnecessary the `-w' and `-e' switches of `perl' binary as well. That's the better I can think that (could) please evaryone (although I know someone will probably not like it...). 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 bother the current way `my' works, and all you'd have to do is not bothering the `scope' pragma exists. Implementing it would certainly be very easy, since the compiler already has to determine the scope of variables, it would only have to determine it in a different way. In Perl 6, where the compiler will be written in Perl, it would be even possible to write it as another front-end to the byte-code generator, but I think it should be a pragma (as strict is, and it does kind of the same thing), since then it and the main compiler would be maintained together. So, I ask: Is this OK with you? Does this bother someone? And: Is there any flaws or holes in my proposal for `use scope'? I've thought about it very much and I can't find any problems and no AAAD. Is there any? I hope I can calm things a bit here, since I'm sure we'll never agree on what's better, this is too much a matter of taste, and we shouldn't discuss taste. - Branden
Re: Closures and default lexical-scope for subs
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 we're concerned about, then, are ones in which > parens are omitted. > > my( $a, $b, $c ) = /(\w+)/g; > > Natural enough, right? Suppose I wanted to use non-my vars here. > > ( $a, $b, $c ) = /(\w+)/g; > > Under your proposal, these must both be equivalent, respectively, to > > my $a, $b, $c = /(\w+)/g; > > $a, $b, $c = /(\w+)/g; > Wrong!!! You mix up my proposal (which is make `my' have less precedence than `,' and `=') with Bryan's one, which is to make everything with `,' be implicitly a list. In the case of my proposal, the code above would be translated to: my( $a, $b, $c ); $c = /(\w+)/g; $a, $b, ($c = /(\w+)/g; If you want a list assignment, you still have to use the parenthesis, like you did above. my ($a, $b, $c) = /(\w+)/g;# or (my $a, $b, $c) = /(\w+)/g; List assignment and declaration of lexical scope are different, but as the declaration of lexical scope can be applied to a list, it should follow the same precedence of list operators, ie. `print', that doesn't *require* but *allows* parenthesis. > I think we can all agree that last won't DWIM, unless the > precedence of the comma operator is changed. > So this illustrates why the issue is not one of changing the > precedence of 'my', but of the comma operator. > It must be lower (i.e. bind tighter) than assignment, > comparison, and the various "operator" functions. Agreed. I don't want to change the precedence between `,' and `=', I only want that `my' behaves in relation to those the same way `print' does. Even these two not being (or doing) the same thing, or even comparable things, they both get lists (agreed, different lists, `my' needs a list of variables) and they both should behave the same when lists are given to them. > > This would upset the entire structure of perl's usefulness. > You're completely right. Messing with `,' and `=' is a bad idea. > -- > John Porter > > You can't keep Perl6 Perl5. > > - Branden
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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, 2 lines of "use" statements are nothing. > >I disagree. We're talking about the added burder of -q in > perl -qe 'print "Just Another Perl Hacker,"' We're not even talking about that. All the -q/-z proponents have said that it should be implied by -e, so one-liners would have unchanged syntax. And people who want their longer scripts to run blissfully free of the ravages of error checking can put -q on the #! line. Whereas the rest of us currently have to remember to put use strict in every blasted .pm. >vs. adding > use strict; > use warnings; >near the top of -- not just one, but probably several or dozens of files. It was only relatively recently that I realized that the one at the beginning of the main program was insufficient :-(
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 differences). But both (potentailly) receive a list of arguments. With `print' (or any other function) I don't need parenthesis if I don't want to put them (and I almost always don't want them). Why with `my' I do need them? Why don't these behave the same? - Branden
Re: Closures and default lexical-scope for subs
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 DTRT and not screw with the precedence of the comma. -- John Porter
Re: Closures and default lexical-scope for subs
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, 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. :) -- "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." (By [EMAIL PROTECTED])
Re: Closures and default lexical-scope for subs
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 know this is bad for who already writes Perl code. But it would be very > good for who learns Perl and doesn't understand exactly when he should and > when he should not put parenthesis around `my's list of variables. If they are learning perl, then when and where to use parentheses is part of the learning curve. This is a Good Thing. MHO, -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN
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. (That's not to say that I don't wish I didn't have to. I *do* wish I didn't have to.) -- John Porter You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
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 > acknowledge that fact, and move on. > Unless you show me why I should, I won't acknowledge it. It's easy to say ``It's better this way'' or ``It's been like this for a long time, it shouldn't change now''. Please just think about it and tell me in which cases `` 'my' having higher precedence than comma is signficantly more useful than if it had a lower precedence'', instead of just saying ``Let's all just acknowledge that fact''. I really can't find one way in which the current behaviour is more `useful'! - Branden
Re: End-of-scope actions: do/eval duality.
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: history. "do FILE" dates from
before "eval BLOCK". The only way it could have been like you say,
would, at the time, have been:
eval "do \'$file\'";
which is simply horrible (and possibly buggy, if $file contains an
apostrophe or a couple of backlashes).
--
Bart.
Re: Warnings, strict, and CPAN
[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. I throw -w and use strict on *every* perl program I
write (since I don't do japhs (much)), and I make sure they run
perfectly clean. (Of course, sometimes I have to
{ local $^W; *foo = sub { ... } }
) And I don't find this particularly onerous.
> strict by default is right out. That's not the sort of language Perl is.
> Supply your own discipline, don't make the language do it or you will
> be sorry.
Not to get into it again; but I have to disagree here.
Better to have to put "no strict;" if you really don't want it.
Programming *intentionally* for strictness violation is not
something that should be encouraged. The onus should be on the
programmer who *wants* to live dangerously.
Of course, in perl6, which has much better granularity and
definability of exceptional condition classes, this argument
may turn out to be moot.
(Sorry, Schwern... Couldn't let you have the last word ;-)
--
John Porter
You can't keep Perl6 Perl5.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 (my($foo),local($"),our($bar),my($baz)) = @_; ;-) -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
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 > > my $a, $b, ($c = @_); It doesn't? > > ie. $a, $b and $c are lexicals, and @_ is assigned to $c in scalar context. > I'm sure I posted this example a while ago. It didn't make sense then, either. Are you saying you wish to declare three lexical variables ($a and $b in void context, and $c to be the scalar value of @_?) > `my' DWIMs. But DWYM ne DWIM ne DWEM ne DWMPM ne DWSPM. This solution is like trying to solve the world's financial problems by taking the richest guy's wealth and distributing it among everyone else. It doesn't solve anything, it just redistributes the problem. > I know this is bad for who already writes Perl code. Then why is it being discussed? > But it would be very > good for who learns Perl and doesn't understand exactly when he should and > when he should not put parenthesis around `my's list of variables. Then maybe the documentation should be improved. Maybe makng a clearer delineation and how and why and when these work are in order. Particularly once attributes come out in full force, which will also bind more tightly than , or =. Simply offloading and compounding the problem isn't a viable solution. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 rule than $a ? I know I wouldn't! It actually isn't hard for us to know `my' should have parenthesis when used for more than one variable, but it's a difficult thing for beginners. The fact with the makes the things even more hard for them. Having `my' with the same precedence rules as `print' for example, would probably end with these problems, while preserving the old-style. my $a, $b, $c; # all the three are lexicals my ($a, $b, $c);# idem my $a, $b, $c = @_; # $c gets @_ in scalar context # which is the same as: $a, $b, $c = @_;# $c gets @_ in scalar context my ($a, $b, $c) = @_; # the same as: ($a, $b, $c) = @_; Only what would change is: func(\my $a, 1, 2); # wouldn't work, but func(\my($a), 1, 2);# or: func(\(my $a), 1, 2); # would work. and: otherfunc my $x => 1# wouldn't work, but otherfunc my($x) => 1 # would work. I don't think it's much of a change, since probably most code that did work would continue to work, except for these cases above here, but I actually think those aren't the most common cases of usage. Oh! Of course, there's also the monster Bryan C. Warnock wrote: (my $a, $b, local $,, my $c) = @_; This very common (I use it in all my scripts!) snippet would have to be rewritten to the much more confuse (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? - Branden
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 changing this in Perl6 doesn't seem like a big leap to me. It's essentially the same as saying that all the deprecated perl5 features will be absent in perl6.0. -- John Porter You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
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 overarching goal of perl's design; being useful to the programmer is. It turns out that 'my' having higher precedence than comma is signficantly more useful than if it had a lower precedence. Let's all just acknowledge that fact, and move on. -- John Porter Ann wenno haddum billizac...
Re: Closures and default lexical-scope for subs
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 unexpected' for a larger > percentage of perl programmers out there. False. Use strict catches this right away. > 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); WHY? WTF does that buy you? It just breaks everything! > And if you say something like: > $a, $b, $c == 10, $d == 11 > you need to disambiguate the sub-statements by saying > $a, $b, ($c ==10), ($d == 11) 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 Porter Ann wenno haddum billizac...
Re: Closures and default lexical-scope for subs
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 = @_;# $c gets 10 for @_=(1..10) mean a different thing that my $a, $b, $c = @_; # $c gets 3 for @_=(1..10) The last code should behave as my $a, $b, ($c = @_); ie. $a, $b and $c are lexicals, and @_ is assigned to $c in scalar context. I'm sure I posted this example a while ago. > That's going to affect some compound expressions, but those can easily be > fixed by liberal uses of the 'scalar' operator, er, function, er, term. > Oh, wait. That also doesn't behave quite right. That can also be tweaked, > I'm sure. > I'm not saying anything about changing `scalar'. It DWIMs all the time. That's certainly not the case with `my'. > But what does that give you? `my' DWIMs. > You've now taken several existing behaviors of the language and completely > changed it for no *net* improvement to the language. (Okay, that may be > subjective, but feel free to argue how what you've added significantly > outweighs a) what you've changed, and b) the fact that you changed it.) > I know this is bad for who already writes Perl code. But it would be very good for who learns Perl and doesn't understand exactly when he should and when he should not put parenthesis around `my's list of variables. > - you do a complete brain drain before changing existing functionality, and > that change had better provide a huge net improvement to the product, I think that's why we discuss it here. > - you don't make any of these decisions arbitrarily. That's why we argue about it. It's not about changing something just for the fun of it. We must see where it's better, where it's not, if we would pay the price for changing it, if it's worth it. I'm not proposing it because I like changes, but I also don't the not DWIMness of some things of Perl. - Branden
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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. > 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, 2 lines of "use" statements are nothing. I disagree. We're talking about the added burder of -q in perl -qe 'print "Just Another Perl Hacker,"' vs. adding use strict; use warnings; near the top of -- not just one, but probably several or dozens of files. > Also, many modules on CPAN have been > in beta for years, and not just 0.99 beta but 0.02 beta, broken and > uninstallable. There's also a lot of modules that don't run under -T. > But "strict" won't fix these issues. But consider that lots of CPAN will be irreparably broken by the change to perl6. So in some sense we're starting with a much cleaner slate than is supposed. -- John Porter You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
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. (my $a, $b, local $,, my $c) = @_; I suppose the counter argument is you could then write that as (my($a),our($b),local($,),my($c)) = @_; Surely that would then allow (my $a, $b, $c) = @_; to be the same as my ($a,$b,$c) = @_; Oh, wait, commas are now implicitly parenthesized, so that (my $a, $b, $c) = @_; can be written as my $a, $b, $c = @_; That's going to affect some compound expressions, but those can easily be fixed by liberal uses of the 'scalar' operator, er, function, er, term. Oh, wait. That also doesn't behave quite right. That can also be tweaked, I'm sure. But what does that give you? You've now taken several existing behaviors of the language and completely changed it for no *net* improvement to the language. (Okay, that may be subjective, but feel free to argue how what you've added significantly outweighs a) what you've changed, and b) the fact that you changed it.) Now, admittedly, I've not done very much language design, but even in generic software design: - you think hard before adding functionality, and that added functionality had better provide a net improvement to the product, - you think even harder before removing functionality, and that the removal of functionality had better provide a larger net improvement to the product, - you do a complete brain drain before changing existing functionality, and that change had better provide a huge net improvement to the product, - you don't make any of these decisions arbitrarily. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
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 > >
Re: Closures and default lexical-scope for subs
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 the source of the problem, since `my' was derived from it and `our' from `my'. 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. - Branden
Re: Closures and default lexical-scope for subs
<[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, more pointless changes with perl5. > If this makes `my' DWIM, I think it's not pointless... - Branden
Re: Closures and default lexical-scope for subs
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 `print' would be good. When you want to my and assign an array of variables you would just my($a, $b, $c) = @_; or (my $a, $b, $c) = @_; The case my $a, $b, $c = @_; should be my $a, $b, ($c = @_); which for that case of @_=(1..10) should result in $c==3, which is the expected. Both ways are possible though. - Branden
Re: Closures and default lexical-scope for subs
<[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) = @_; or even my($a, $b, $c) = @_; ## current syntax keeps working. - Branden
Re: Closures and default lexical-scope for subs
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)
Re: Closures and default lexical-scope for subs
<[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; # or tie (my $shoe) => $tring; I see no problem with those, even if my binds weaker than it binds now. Quoting from perlfunc: ``It LOOKS like a function, therefore it IS a function'' Not I'm not saying `my' should be changed. Its way of working is already in our subconscients. Changing it would be probably bad. But it surely isn't consistent with the rest of the language. - Branden
Re: defined: Short-cutting on || with undef only.
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 viewed as string or number will be "" or 0, but > > will evaluate as true in a condition. > > You mean the beaten-to-death ??, formely known as |||, operator? > > It has torn p5p to shreds repeatedly. Perhaps Branden should take up the issue on the Perl-defop mailing list, which was set up for discussion of this operator. However, the last two postings I have in my archive are from August 1999 and October 2000 (this one being Ask proposing closing the mailinglist since it seemed to be receiving no traffic). But yes, it's been discussed in p5p several times. There was even code posted to p5p at one point that would introduce the operator (spelled, I believe, |||) into the sources. Cheers, Philip -- Philip Newton <[EMAIL PROTECTED]> I appreciate copies of replies to my messages to Perl6 lists.
