Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Wed, 21 Feb 2001 16:01:39 -0500, [EMAIL PROTECTED] wrote: Has anyone actually used a language which has run-time warnings on by default? Or even know of one? Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal error in those languages. Trying to read the value of an uninitialized variable, for example, that's commonly a fatal error. Failing to chdir, is another example. So even with warnings on by default, Perl is still pretty mild. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote: On Wed, 21 Feb 2001, Bart Lateur wrote: Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal error in those languages. Examples? I know you're not talking about C or C++. Visual Basic, for one, or any other BASIC in history. It looks like a compiled vs. interpreted thing. C doesn't do any runtime error checking, because of speed reasons. There's no array bounds checking. You can use a null pointer when copying a string, which results in an untrappable program error ;-). Virtually all interpeted languages, where safety reigns over speed, do all of those. Anything out of the ordinary is a fatal error. AppleScript is an extreme example. There, if you're trying to get a list all picture boxes of a certain type on a page, it works properly if there is one or more. But if there is isn't one, you don't just get the empty list. No: it's a fatal (but trappable) error. That kind of anal behaviour in a language is extremely annoying. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Sam Tregar wrote: [EMAIL PROTECTED] wrote: Well, an unhandled exception in Java is death for the program. Yup. So all (potentially) exceptions are "fatal errors"? Well, that definition fits "almost meaningless" pretty well, in my opinion! Not exactly. Java defines two clases of "throwables": Exceptions, which must be caught if declared to be thrown (the standard class libraries throw a lot of these), and Errors, which are not normally caught. The latter includes signal-like conditions such as VirtualMachineError, LinkageError, and ThreadDeath. -- John Porter
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Bart Lateur [EMAIL PROTECTED] wrote:
On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote:
On Wed, 21 Feb 2001, Bart Lateur wrote:
Actually, it's pretty common. Only, most languages are not as
forgiving
as perl, and what is merely a warning in Perl, is a fatal error in
those
languages.
Examples? I know you're not talking about C or C++.
Visual Basic, for one, or any other BASIC in history. It looks like a
compiled vs. interpreted thing. C doesn't do any runtime error
checking,
because of speed reasons. There's no array bounds checking. You can use
a null pointer when copying a string, which results in an untrappable
program error ;-). Virtually all interpeted languages, where safety
reigns over speed, do all of those. Anything out of the ordinary is a
fatal error.
Ah... point of order:
C doesn't do these checks because it expects you to do so; not because of
language limitations, but because of language level (i.e. "low"... one
step above assembler). VisualBasic actually does surprisingly little,
though it (and Delphi/Pascal) does a bit more than C: otherwise you
wouldn't need an On Error Goto Label in every other function to avoid one
of those hopelessly meaningless MicroSoft-style errors popping up for no
better reason (your code is still good) than that MS is not capable of
providing good libs despite their horriffic overbloat.
Perl was designed to be non-annoying, not inherently correct. A mistake is
still a mistake, just far less likely to totally crash the program (and
the operating system). Actually, in many places, it was designed to make
decent assumptions. This is what's scaring me about all this talk about
exceptions... it can break this mold and make Perl into a "complainer
language" belching up uncaught (don't care) exceptions forcing try/except
blocks around every piece of IO or DB handling. The style
try {
open(FOO, "./foo");
}
catch FileOpenException $e {
die "Drat:" .$e-Message. "\n";
}
is horrifying to me over the normal
open(FOO, "./foo") or die "Drat:$!\n";
The first is just plain unnatural. Geez, it's outright Pythonic (or
Javanic). I'll take (C++):
if((f=open("./foo","r"))==NULL) { ... exit(1); }
over
try {
f = new MyFileClass(f, "./foo", "r");
}
catch ExFileOpenError e {
... exit(1);
}
catch ExFileExistError e {
... exit(1);
}
catch ExFilePermissionError e {
... exit(1);
}
catch ExOpSysError e {
... exit(1);
}
catch ExBadDesignError e {
... exit(1);
}
catch ExMeaninglessError e {
... exit(1);
}
anyday. This doesn't "get error checking out of your way" it shoves it in
your face.
FWIW Perl doesn't do bounds checking because it assumes that if you go out
of bounds then you want to go out of bounds and it creates new bounds. Or
at least that's how I see it. That's not so subtle a difference. The
languages that I've seen do this follow Perl's lead (not the other way
around), and those are very few from what I've seen.
One of my longstanding points of advocacy for Perl has been "I learned
more from perl by experimenting than by reading: no matter what I threw at
Perl, it almost always did it right anyway. I made up bits and pieces of
grammar as I went along." Try that with another interpreted language.
Please don't ascribe angelicity to VB. It's just a bad toy language behind
a wizard gui. It may do bounds checking, but makes up for that by erroring
out at runtime at the stupidest places imaginable and giving no clue
what's wrong without an entire string of GOTO's, and even then it's
doubtful you'll get an error message worth the CPU cycles to display.
p
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
At 09:36 AM 2/22/2001 +, David Grove wrote:
This is what's scaring me about all this talk about
exceptions... it can break this mold and make Perl into a "complainer
language" belching up uncaught (don't care) exceptions forcing try/except
blocks around every piece of IO or DB handling. The style
try {
open(FOO, "./foo");
}
catch FileOpenException $e {
die "Drat:" .$e-Message. "\n";
}
is horrifying to me over the normal
open(FOO, "./foo") or die "Drat:$!\n";
Now steady on. No-one is proposing getting rid of the normal way of doing
it. We're just talking about beefing up another WTDI. There are situations
in programs that have dozens or hundreds of lines of code which benefit
from the exception model just as much as your example.
RE: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] ... The basic usefulness of warnings is not in question. This is about the *perception* of their utility. Warnings are only useful if the user heeds them. The question is, will having them on by default make the user more or less likely to respond? There was also eariler discussion that this might encourage people to cover up large sections of lousy code with a Cno warnings thus further burying potential errors and actually worsening the situation. Some ideas were kicked around to have a way to globally override Cno warnings... This is what the -W command-line flag does. but it seems like we're right back to having to remember -w again. Paul _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
At 10:48 AM 2/22/2001 +0100, Bart Lateur wrote: On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote: On Wed, 21 Feb 2001, Bart Lateur wrote: Actually, it's pretty common. Only, most languages are not as forgiving as perl, and what is merely a warning in Perl, is a fatal error in those languages. Examples? I know you're not talking about C or C++. Visual Basic, for one, or any other BASIC in history. It looks like a compiled vs. interpreted thing. Not necessarily. My C compiler throws out the equivalent of perl's "use of undefined value" error. Granted it only whines about the use of uninitialized variables, and ones that can be detected at compile time, but the checks are still there. C doesn't do any runtime error checking, because of speed reasons. There's no array bounds checking. Also not quite true anymore. Some C compilers will do array bounds checking for you at run time. Compaq C will, though it's off by default because of the speed penalties involved. You can use a null pointer when copying a string, which results in an untrappable program error ;-). Nah, that's trappable too, if you know what you're doing. :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Has anyone actually used a language which has run-time warnings on by default? Or even know of one? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Are we still having this discussion? :-) At 07:23 PM 2/21/01 -0500, [EMAIL PROTECTED] wrote: Its true alot languages would consider many of Perl's warnings to be errors, that's not really analgous to what we're talking about here. Run-time errors aren't quite in the same spirit as run-time warnings. A run-time error is something the language defines as being explicitly bad or a mistake (even if it can be caught as an exception). Run-time warnings are just the language saying, "excuse me, there might be a problem here". An error is, "NO, YOU'RE WRONG!!" Errors and exceptions must be dealt with, else your program won't run. Warnings... they can be ignored. I do not think there is hard dividing line between warnings and errors. "Unable to establish network connection - saving file to local disk" means the program is still running afterwards. The more fault-tolerant your program is, the more your errors look like warnings. Is that message an error or a warning? Warnings are often stylistic in nature, errors are not. An error is often a very concrete indication that something is wrong, a warning is not (if it was, it should be promoted to an error). With that in mind, do we have any analogies? I can think of some GUI analogies. Macster (the Macintosh Napster client)* requires that you confirm every download you cancel. Windows, by default, requires that you confirm everything you drop into the trash (or whatever they call it this week). Most software installers require that you click [Accept] after reading the agreement. Some even require that you scroll down to the bottom before letting you accept. The result? People either shut them off or mindlessly click [Ok]. Nobody** sits there and things "gee, do I really want to throw this out?" Nobody reads software licenses. Or government warnings on cigarettes. Its not that there's anything wrong with these ideas, but its the continual bombardment which dulls the senses against them. If the user has internalized the need for them (say, they once deleted a file which cost them their job) then it might be helpful. Similarly, a wet-behind-the-ears programmer will not give Perl's warnings much credence if their program runs fine despite of them. They will be ignored until such time as they internallized, through error or teaching. I suppose I'm in an exceptional class then, 'cos whatever language I'm using, any warning at any time causes me to stop what I'm doing, and fix the cause. Even if that means selectively ignoring the warning through a pragma. I've been doing this since I used Saber C (actually before that, too): fix the cause, or put an ignore directive in. Never mind how picky it seems. I am somewhat frightened by the prospect of anyone programming with a mindset that warnings are okay, and even more by the philosophy that we should cater more to them than more careful people. What if the warnings were: 1/100 chance of destroying your files at this point... you win! 1/100 chance of producing incorrect output at this point... you win! 1/100 chance of losing user data at this point... you win! ... What if the warnings boiled down to that anyway? -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Its true alot languages would consider many of Perl's warnings to be errors, that's not really analgous to what we're talking about here. Run-time errors aren't quite in the same spirit as run-time warnings. A run-time error is something the language defines as being explicitly bad or a mistake (even if it can be caught as an exception). Run-time warnings are just the language saying, "excuse me, there might be a problem here". An error is, "NO, YOU'RE WRONG!!" Errors and exceptions must be dealt with, else your program won't run. Warnings... they can be ignored. Warnings are often stylistic in nature, errors are not. An error is often a very concrete indication that something is wrong, a warning is not (if it was, it should be promoted to an error). With that in mind, do we have any analogies? I can think of some GUI analogies. Macster (the Macintosh Napster client)* requires that you confirm every download you cancel. Windows, by default, requires that you confirm everything you drop into the trash (or whatever they call it this week). Most software installers require that you click [Accept] after reading the agreement. Some even require that you scroll down to the bottom before letting you accept. The result? People either shut them off or mindlessly click [Ok]. Nobody** sits there and things "gee, do I really want to throw this out?" Nobody reads software licenses. Its not that there's anything wrong with these ideas, but its the continual bombardment which dulls the senses against them. If the user has internalized the need for them (say, they once deleted a file which cost them their job) then it might be helpful. Similarly, a wet-behind-the-ears programmer will not give Perl's warnings much credence if their program runs fine despite of them. They will be ignored until such time as they internallized, through error or teaching. * I expect the Feds to be knocking down my door any minute now. ** s/Nobody/Just about no one/ for the picky. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Can you give me an example of the former?
I can't think of any off the top of my head.
Scalar value @foo[$bar] better written as $foo[$bar], for one.
If part of Perl's breeding is autovivication and interpretation of undef as
0 or "" in the appropriate context, why should Perl bitch at me if I use it
as such? Why should I have to ask permission to do so?
Well, for one, your example is ill-considered. You are going to get
autovivification saying:
@foo[$bar] = 1;
just as much as you are going to get autovivification for:
$foo[$bar] = 1;
Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.
Second, with the keyword empty (if it comes to pass) the reasons for
interpretation of undef as 0 and "" go away. Right now, things are a PITA
to get empty values:
my ($a, $b, $c, $d, $e) = ('') x 5;
With empty:
my ($a, $b, $c, $d, $e) = empty;
I would rather say, and I think it would be more perlish to say, "I'm not
feeling particularly perly today, can you check for anything clever, cause
if there is, chances are it's a mistake."
Or how about "I'm feeling particularly lazy today, I think I'll sleep in. Lets
worry about any mistakes I might make another day."
For i maintain that any 'cleverness' that you might have that causes warnings
in perl6 will *probably* be a mistake.
Ed
Re: Closures and default lexical-scope for subs
At 05:27 PM 2/19/01 +, Piers Cawley wrote: Peter Scott [EMAIL PROTECTED] writes: I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo = \my ($foo), bar = \my $bar); If you're really all for maintainability, then surely you mean: GetOptions (foo = \my ($foo), bar = \my ($bar)); otherwise some dumb hacker (eg. You, two weeks later) could come to add annother pair of args by sticking C, baz = \my $baz into the args list... Yup, yup. tie my ($shoe) = $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? Do you not *care* how ugly you're making something that was once compact, expressive and elegant? Of course I care. I just weighed the advantage (consistency, intuitiveness in the case of my $a, $b, $c which is far more common than either of the above) against the disadvantage and decided it was worth it, on balance. Subscribers to different value systems may have different results. And if it's not a function then WTF do you want to make it look like one, potentially sowing more confusion. I'd be happy to retract my position if someone would take the thing out of perlfunc then. I'd really also like to see a more definitive description than "language construct" at the same time. -- Peter Scott Pacific Systems Design Technologies
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Yep; the perl manpage has said, since time immemorial, that | the fact that -w was not on by default is a BUG. I don't know that I would say time immemorial. It wasn't in the man for 4.036. I can only find man pages back to 5.002 right now, so I can't check any earlier than that in the 5 tree. However, it was meant to be (more than) slightly tongue-in-cheek. -spp
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 14:45, Stephen P. Potter wrote: Lightning flashed, thunder crashed and John Porter [EMAIL PROTECTED] whispered : | Yep; the perl manpage has said, since time immemorial, that | the fact that -w was not on by default is a BUG. I don't know that I would say time immemorial. It wasn't in the man for 4.036. I can only find man pages back to 5.002 right now, so I can't check any earlier than that in the 5 tree. However, it was meant to be (more than) slightly tongue-in-cheek. And there's a difference between warnings originating because something has gone wrong and those originating because I'm doing something particularly perlish. Unfortunately, -w doesn't (and probably can't) tell the difference. sidetrack A friend of mine was attempting to install some commercial program (a DD character generator, IIRC) on a Windows box - one that didn't have a sound card. It wouldn't run. It always crashed while trying to talk to the sound card. He procured someone else's laptop to do a demo install, and it ran fine - there are open and close window sound effects, and this voice-over guy that gives instructions. The first instruction given in the setup box? If you'd like to turn off the voice, click this box. Nothing else is sound dependent. Somehow I think there's a lesson to be learned here. /sidetrack -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
Bryan C. Warnock wrote: And there's a difference between warnings originating because something has gone wrong and those originating because I'm doing something particularly perlish. Unfortunately, -w doesn't (and probably can't) tell the difference. Can you give me an example of the former? I can't think of any off the top of my head. -- John Porter
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 16:03, John Porter wrote: Bryan C. Warnock wrote: And there's a difference between warnings originating because something has gone wrong and those originating because I'm doing something particularly perlish. Unfortunately, -w doesn't (and probably can't) tell the difference. Can you give me an example of the former? I can't think of any off the top of my head. Scalar value @foo[$bar] better written as $foo[$bar], for one. (But you probably would have thought of that if I had said something better than "something has gone wrong" which doesn't describe the above at all. I'm sorry, a completely horrible phrasing of what I was trying to say - I'll take me out back and shoot me now.) I'll try this again - the difference between a perceived user error, and a misused perl construct. The above error reflects an inability to distinguish between mulitple typos: either $foo or a list index. If part of Perl's breeding is autovivication and interpretation of undef as 0 or "" in the appropriate context, why should Perl bitch at me if I use it as such? Why should I have to ask permission to do so? I would rather say, and I think it would be more perlish to say, "I'm not feeling particularly perly today, can you check for anything clever, cause if there is, chances are it's a mistake." -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote:
Scalar value @foo[$bar] better written as $foo[$bar], for one.
I agree on this one (hash slices too), if this expression is in list
context. There is no error in
@r = map { blah } @foo{$bar};
--
Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
What it boils down to is, warnings are for perl to tell you when you probably made a logic error, based on the perl code it sees. What some people might think is merely unperlish code, others might say is "horribly wrong". -- John Porter
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tue, Feb 20, 2001 at 08:33:50PM -0500, Bryan C. Warnock wrote:
On Tuesday 20 February 2001 19:34, Edward Peschko wrote:
Well, for one, your example is ill-considered. You are going to get
autovivification saying:
The two ideas were disjoint. The example wasn't an example of autoviv.
well, I was thinking you were saying @foo[$bar] = 100;
Hence I'd say that @foo[$bar] has NO INTRINSIC VALUE whatsoever.
Correct, which is why I could care less if Perl warns me about it.
right, but which is the higher cost? 10 experienced people being inconvenienced
because they see a message they can easily avoid, or 1 people learning the
language not getting the benefits that they would otherwise get by seeing it.
If perl is squawking to you about something, it usually is because you've got
a misconception of some kind. In this case, the misconception is that something
like:
if (@tmp[1,4] == @tmp[2,5])
{
}
will work.
Second, with the keyword empty (if it comes to pass) the reasons for
interpretation of undef as 0 and "" go away. Right now, things are a PITA
to get empty values:
my ($a, $b, $c, $d, $e) = ('') x 5;
I *like* the interpretation of undef as 0 and "". It's useful. Sometimes.
Sometimes it's not. And that's fine.
No that's NOT fine. It leads to 'find the needle in the haystack' sort of
problems. If you get 1450 'use of undef value' errors, they are all useless.
If you get 10 of them, and you know that the only time you are going to get
'use of undef value' errors, they are very valuable. And how valuable they
are grows as the size of your project increases.
There's no reason in the world why that should replace undef - 0 and "".
See above.
Or how about "I'm feeling particularly lazy today, I think I'll sleep in.
Lets
worry about any mistakes I might make another day."
Well, Laziness is One of the Three.
Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by
default, because warnings and strict are great teaching tools.
Let me rephrase.
Perl shouldn't bitch at me for valid perl.
'-q'.
Ed
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Tuesday 20 February 2001 22:03, Edward Peschko wrote: I *like* the interpretation of undef as 0 and "". It's useful. Sometimes. Sometimes it's not. And that's fine. No that's NOT fine. It leads to 'find the needle in the haystack' sort of problems. If you get 1450 'use of undef value' errors, they are all useless. If you get 10 of them, and you know that the only time you are going to get 'use of undef value' errors, they are very valuable. And how valuable they are grows as the size of your project increases. There's no reason in the world why that should replace undef - 0 and "". See above. Or how about "I'm feeling particularly lazy today, I think I'll sleep in. Lets worry about any mistakes I might make another day." Well, Laziness is One of the Three. Exactly. Perl lets you be as lazy as you want. It just shouldn't do it by default, because warnings and strict are great teaching tools. Let me rephrase. Perl shouldn't bitch at me for valid perl. '-q'. None of that is the point. I don't disagree that having loads of warnings are a good thing. I don't disagree that having strict parsing rules, variable declarations, and the ilk are a good thing. There is no technical reason why warnings and strictness can't be the default. You with me so far? Everything you have said is perfectly valid, and if we were designing a brand-spanking new language, I might be arguing *for* you. But we're not, we're tweaking Perl. Perl, remember that language? The language that advertised all the above laziness? That the above laziness was part of its drawing power? This isn't an addition to the language that you're talking about - it's changing some of the fundamental behavior of the language. It's saying that no longer is Perl a loose, powerful language - oh, you want BD? well, we can do that for you too - but rather that Perl is just another conventional programming language, (although if you flip this switch, you'll get its old, horrible behavior.) Sure, it will be easier to learn - it had better be, because *e-v-e-r-y-o-n-e* is going to have to learn it. Again. Look, most folks are probably sick of us going round and around about this, so I'll sum up my position. 1. There is no technical reason why warnings and strict can't be on by default, why undef must be able to promote to 0 or "", or just about any other feature a computer language can have. No technical reason. It may break some things, but those things can be fixed in their own right. 2. There are many non-technical reasons not to change codified behavior. This is why the last serious revamp of English spelling and grammar rules were aborted by the publication of the dictionary, why Americans adamantly refuse any doings with the metric system (except the 2 liter bottle), and why sports fans hate the instant replay. To change what some consider the philosophical essence of Perl is akin to a bait-and-switch, and I, for one, would feel cheated, (and if you'll allow me to wax melodramatic, betrayed). 3. While the argument is internal to us, I will remain steadfast in my stance against any arbitrary, widespread reversal of the language. 4. Should the Perl cabal deem that, for Perl to improve, it *must* undergo these radical changes, I will, to the best of my meager abilities, attempt to implement them. My position may seem a bit extreme - after all, didn't I, in the second RFC, attempt to autoprint statements in a void context? I started in the middle of the road, but as arguments like this have continued, I've moved wy to the minimalist's side. Hey, overhaul Perl to your heart's content so that you're able to do x, y, and z; just so long as Perl itself doesn't do x, y, and z. -- Bryan C. Warnock [EMAIL PROTECTED]
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
This isn't an addition to the language that you're talking about - it's changing some of the fundamental behavior of the language. It's saying that no longer is Perl a loose, powerful language - oh, you want BD? well, we can do that for you too - but rather that Perl is just another conventional programming language, (although if you flip this switch, you'll get its old, horrible behavior.) I never said it was its 'old horrible' behaviour. We've got to stop thinking about this as a religious issue. I have no qualms with people using something like '-q', hell, I'll use it myself. The only thing is that it has a *huge cost*, this laxness by default. And the cost is not only technical: 1) diminished reputation. 2) misconceptions on news groups, mailing lists 3) wasted time, frustrations from users saying perl is 'quirky' 4) poorer quality of 3rd party modules, persistent bugs in them. 5) -w as pariah, ignored warnings. In order to get the big, big, win. warnings have to be on by default, and they have to be intuitive and easy enough to use by being on by default. If that means we clean up both warnings (getting rid of some of the sillier ones) and the method of using warnings up unto the point that they are flexible enough *to* be included by default, well that's the price we will have to pay in order for it to work. If it means that we turn on warnings strict on by default and give it a 'trial run' to get the perl community's feedback, get their positive feedback and iterate that means we do that. Unlike most other changes that we decide on, this one is *undoable*. If it doesn't work, and there is a big rebellion, well, it doesn't work and there is a big rebellion. We say it was a noble experiment and move on. But if it *does* work, then great. There's no reason to feel betrayed - its a simple experiment: I think that this is doable, and will help a lot. You think its not doable for cultural reasons. Good - then let the culture decide. But don't sell it short until you've seen it done. The least we get out of it is a cleaner, better warnings model and a Its all a matter of attitude, of selling people that its a good idea by not forcing it down their throats but by presenting them with something and asking them to use it, and getting their *opinion* on it. As for innovation, I really don't know of any language that helps users by pointing out potential mistakes... And that's the last *I'm* going to say on the subject. I'm better off writing RFC's... Ed
Re: Closures and default lexical-scope for subs
Peter Scott [EMAIL PROTECTED] writes: At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote: However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: Personally, I don't think so. GetOptions (foo = \my $foo, bar = \my $bar); and tie my $shoe = $tring; are just way too practical to suddenly require more hoops. I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo = \my ($foo), bar = \my $bar); If you're really all for maintainability, then surely you mean: GetOptions (foo = \my ($foo), bar = \my ($bar)); otherwise some dumb hacker (eg. You, two weeks later) could come to add annother pair of args by sticking C, baz = \my $baz into the args list... tie my ($shoe) = $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? Do you not *care* how ugly you're making something that was once compact, expressive and elegant? And if it's not a function then WTF do you want to make it look like one, potentially sowing more confusion.
Re: The binding of my (Re: Closures and default lexical-scope for subs)
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. Very true. But we are all familiar with Perl. While teaching Perl classes I often encounter people that have a hard time getting used to the peculiarities _we_ are familiar with. 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. After all, the trainees of today are the Perl programmers of the future. -- Johan
Re: The binding of my (Re: Closures and default lexical-scope for subs)
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 be) for the learner; Larry wants Perl to be optimized for the programmer. Unfortunately, to the two optimizations are mostly disjoint. -- John Porter Fortunaut
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
[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
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
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
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: 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
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: 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: 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: 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 FHANDLE 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: 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)
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
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: 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: 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: 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: 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: 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 qd 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
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: 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
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: 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: 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: 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)
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
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: 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: Closures and default lexical-scope for subs
First of all, sorry to bother you again with this issue, but I guess it
didn't have the appropriate discussion. If you're not interested, please
don't read further...
I wrote:
I expect Perl 6 will have some way to define its variables as being
lexical-scoped in the sub they are used as default, either by the language
default, or by a pragma, as `use scope "subs"; ', as it's proposed in RFC
64.
John Porter wrote:
Well, since the former isn't going to happen, the latter isn't going to
be a problem.
and Michael G Schwern wrote:
I believe this issue was discussed to death on the mailing list Way
Back When and IIRC the result was "its too much trouble to eliminate
two characters". There's heaps and heaps of caveats, arbitrary
decisions and conflicts to be resolved about how the auto-lexical
scoping should work. All this so you don't have to type "use strict"
and the occasional "my".
[snip]
Anyhow, I could be completely wrong about how the discussion turned
out. Check the archives.
Well, I checked the archives, and I found that the discussion begun in
http:[EMAIL PROTECTED]/msg01441.html and the
last post about it was in
http:[EMAIL PROTECTED]/msg01567.html, by Bart
Lateur. And that post was IMO beginning to go into a different direction,
but I saw no comments about it. Did I miss something in the archives? I
looked for it in perl6-language-strict as well but found nothing.
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern) languages do
it and most programmers are used to it. And `my' really doesn't DWIM. For
example,
my $a, $b, $c;# only $a is lexically scoped
my ($a) = FHANDLE; # after deducing (by the above)
# that I should include parenthesis
# around every `my', this example
# comes to read the whole file
# when I wanted only the first line.
if ($x) {
my $y = 1;
} else {
my $y = 2;
}
return $y;# wrong, since my makes $y above
# only inside the if/else blocks.
# I have to do:
my $y;
if ($x) {
$y = 1;
} else {
$y = 2;
}
return $y;
# I know you'll say I could use
my $y = $x ? 1 : 2;
return $y;
# But suppose I wanted to write more code
# inside the if/else blocks and supply a
# return value.
These are the problems I see with `my', not to mention the problems that
arise by NOT having `my' (these are quite well described in RFC 64).
My proposal is: As most code written SHOULD have (almost) all its variables
lexically scoped, in presence of a pragma (like `use scope'), all variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in. To access variables outside of this
scope, keywords would be used to statically define that a variable actually
refers to a global variable or a variable of another scope.
I propose the introduction of two new keywords (just like `my' and `our')
for specifying a different scope: `global' and `outer'. `global' would be
used to say that a specific variable or a list of them would refer to the
global variables with those names in the current package. `outer' would be
used to say that a specific variable or a list of them would refer to the
same variables in the `parent' level (that would be used for closures).
Variables accessed with their explicit full packagenames would be the global
variables. Variables in the top-level in the file would be file-scoped. subs
that want to access these file-scoped variables do it with `outer'. `my'
would still be allowed, for lexically scoped variables inside some blocks
inside a sub that should have variables of its own.
When I originally wrote my `outer' proposal (it was named other thing then),
John Porter wrote:
Ugh - upvar? No thanks.
Actually, what I'm proposing is quite very different than `upvar'. `upvar'
is a dynamic thing, it accesses a variable in the scope of the caller.
`outer' is a lexical thing, it tells the compiler that that variable name is
accessing the same variable that the definer was accessing.
For example:
# In a very Perlish Tcl...
my $x = 1;
sub foo {
upvar $x;
print $x;
}
sub bar {
my $x = 2;
foo();
}
bar();
# would print 2
my $x = 1;
sub foo {
outer $x;
print $x;
}
sub bar {
my $x = 2;
foo();
}
bar();
# would print 1
As `outer' accesses the variable of the `definer' and when it was `defined',
it accesses the file-scoped `$x', instead of the caller's (bar's) `$x', that
is what would happen with Tcl's `upvar'.
--
Examples of usage:
use scope;
sub foo {
$bar = shift;
if ($bar) {
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote: I propose the introduction of two new keywords (just like `my' and `our') for specifying a different scope: `global' and `outer'. `global' would be used to say that a specific variable or a list of them would refer to the global variables with those names in the current package. What are "global variables"? Do you mean those that have file scope? Variables accessed with their explicit full packagenames would be the global variables. Wait, I thought we were talking about lexicals, not dynamics. Actually, what I'm proposing is quite very different than `upvar'. `upvar' is a dynamic thing, it accesses a variable in the scope of the caller. `outer' is a lexical thing, it tells the compiler that that variable name is accessing the same variable that the definer was accessing. I'm confused. Consider also I'm not wanting you to use it, or like it whatsoever. I only think it would probably be useful for some of us, and that only adding a new `scope' pragma wouldn't hurt anybody, while possibly helping some. Perhaps. Except that you also propose to burden the language with two new keywords. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 01:40:53PM -0300, Branden wrote: I propose the introduction of two new keywords (just like `my' and `our') for specifying a different scope: `global' and `outer'. `global' would be used to say that a specific variable or a list of them would refer to the global variables with those names in the current package. What are "global variables"? Do you mean those that have file scope? Sorry... dynamics. These are the ones that are in a package namespace. Variables accessed with their explicit full packagenames would be the global variables. Wait, I thought we were talking about lexicals, not dynamics. Again package vars. Actually, what I'm proposing is quite very different than `upvar'. `upvar' is a dynamic thing, it accesses a variable in the scope of the caller. `outer' is a lexical thing, it tells the compiler that that variable name is accessing the same variable that the definer was accessing. I'm confused. Consider also I'm not wanting you to use it, or like it whatsoever. I only think it would probably be useful for some of us, and that only adding a new `scope' pragma wouldn't hurt anybody, while possibly helping some. Perhaps. Except that you also propose to burden the language with two new keywords. Only if `use scope' is used, otherwise, the keywords would have no meaning. - Branden -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
Branden wrote:
Well, I checked the archives, and I found that the discussion begun in
http:[EMAIL PROTECTED]/msg01441.html
That thread was rather tame; even so, I believe the end result,
if one can be deduced, is that the proposal is not a good one.
There was more heated discussion in the thread rooted at
http://www.mail-archive.com/perl6-language@perl.org/msg01089.html
the discussion of RFC 16.
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern) languages do
it
This is false. Even languages in which lexical variables are the
norm still require a variable declaration; it's not a "default".
And `my' really doesn't DWIM.
Only if WYM isn't what 'my' does. :-)
my $a, $b, $c;# only $a is lexically scoped
RTFM.
my ($a) = FHANDLE; # after deducing (by the above) . . .
# when I wanted only the first line.
Silly beginner gotchas. It's not an inconsistency of the
language by any means.
if ($x) {
my $y = 1;
} else {
my $y = 2;
}
return $y;# wrong,
Just as in any language with lexical variables:
if ( x ) {
int y = 1;
} else {
int y = 2;
}
return( y ); /* wrong */
These are the problems I see with `my', not to mention the problems that
arise by NOT having `my' (these are quite well described in RFC 64).
Except they're not really problems, volumes of discussion
not withstanding.
My proposal is: As most code written SHOULD have (almost) all its variables
lexically scoped, in presence of a pragma (like `use scope'), all variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
This introduces far more serious problems than it purports to solve.
To access variables outside of this
scope, keywords would be used to statically define that a variable actually
refers to a global variable or a variable of another scope.
I see. Instead of
sub {
my $x;
{
$x = 1;
{
$x = 2;
{
$x = 3;
{
$x = 4;
}
}
}
}
}
You'd have to write
sub {
$x = undef; # to establish it at this scope
{
outer $x = 1;
{
outer 2 $x = 2;
{
outer 3 $x = 3;
{
outer 4 $x = 4;
}
}
}
}
}
Yeah, that's much better. :-P
I propose the introduction of two new keywords
As I said before: ain't happenin'.
Ugh - upvar? No thanks.
Actually, what I'm proposing is quite very different than `upvar'. `upvar'
is a dynamic thing, it accesses a variable in the scope of the caller.
`outer' is a lexical thing, it tells the compiler that that variable name is
accessing the same variable that the definer was accessing.
You are so confused. As you say, upvar deals with scope. That's
lexical. It is *not* dynamic, which deals with namespaces.
(The documenation of upvar may talk about "global variables",
but that's just referring to the outermost lexical scope.)
So, yes, indeed, you are proposing a sort of upvar for perl. Blech.
Note that discussion of upvar also occurs under the discussion
of RFC 143.
Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in contrast
to `outer($x), $y, $z'.
Great. You want to break this one very consistent aspect of perl.
I predict that you're going to say that this isn't saving typing,
No, I'm going to say that it introduces far more serious problems
than it purports to solve.
Furthermore, it adds more ways -- unnecessary ways at that -- to
do things, and more confusion for our already befuddled newbies.
writing modules that essentially need to use lexically scoped variables to
guarantee they won't harm scripts that use those modules, I think it's a
win.
use strict 'vars' + my is already more than sufficient to this need.
I also see no action at a distance here, since the only way to change the
...
assuming `our' *outside* the block would affect variables inside the block.
I have to disagree with you.
--
John Porter
You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
John Porter wrote:
Well, first let me say why I think a way (pragma) to do lexical-scope by
default (for one file/block/scope) would be good. Most (modern)
languages do
it
This is false. Even languages in which lexical variables are the
norm still require a variable declaration; it's not a "default".
Take PHP and Python, for example.
my $a, $b, $c;# only $a is lexically scoped
RTFM.
my ($a) = FHANDLE; # after deducing (by the above) . . .
# when I wanted only the first line.
Silly beginner gotchas. It's not an inconsistency of the
language by any means.
Yeah. Beginners. I was one too. And I remember always falling on these...
But that's OK, since we probably don't want any new Perl programmers...
My proposal is: As most code written SHOULD have (almost) all its
variables
lexically scoped, in presence of a pragma (like `use scope'), all
variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
This introduces far more serious problems than it purports to solve.
Tell me one. I couldn't find it.
To access variables outside of this
scope, keywords would be used to statically define that a variable
actually
refers to a global variable or a variable of another scope.
I see. Instead of
sub {
my $x;
{
$x = 1;
{
$x = 2;
{
$x = 3;
{
$x = 4;
}
}
}
}
}
You'd have to write
sub {
$x = undef; # to establish it at this scope
{
outer $x = 1;
{
outer 2 $x = 2;
{
outer 3 $x = 3;
{
outer 4 $x = 4;
}
}
}
}
}
Wrong! Read again:
My proposal is: As most code written SHOULD have (almost) all its
variables
lexically scoped, in presence of a pragma (like `use scope'), all
variables
would be implicitly defined as lexically scoped to the named sub (not
anonymous blocks, only subs) they're in.
***(not anonymous blocks, only subs)*** Got it?
The only change would be cutting the `my $x;' line, since all others are in
the same sub. (As you see, `my' introduces a bit more than typing two
characters).
: # under use scope;
: sub {
: {
: $x = 1;
: {
: $x = 2;
: {
: $x = 3;
: {
: $x = 4;
: }
: }
: }
: }
: }
Or, the smart way:
: sub { $x = 4; }
Or even:
: sub { 4 }
Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in
contrast
to `outer($x), $y, $z'.
Great. You want to break this one very consistent aspect of perl.
print $x, $y, $z;
writing modules that essentially need to use lexically scoped variables
to
guarantee they won't harm scripts that use those modules, I think it's a
win.
use strict 'vars' + my is already more than sufficient to this need.
Sufficient? Yes.
The best way? Maybe, maybe not.
The only way? (So long,) Yes.
I think TSBMTOWTDI.
I also see no action at a distance here, since the only way to change
the
...
assuming `our' *outside* the block would affect variables inside the
block.
Hey! You are changing the meaning of what I said!!! I didn't write that!
: I also see no action at a distance here, since the only way to change the
: way a sub sees a variable is inside the sub the variable is being used.
: That's where I think the discussion about RFC 64 was problematic. It was
: assuming `our' *outside* the block would affect variables inside the
block.
: And that's AAAD for sure!
I never said `our' should affect the variables inside the block! I said this
was the *main* problem in the discussion of RFC 64! Having `our' (or
anything) outside the scope change the scope of things is a very bad idea.
It's clear it ends with all the purpose of it.
I have to disagree with you.
Read it again, and see if it has problems or not. Note again, I'm not asking
you to use it, or even like it. I'm only asking if it has the ``far more
serious problems than it purports to solve'' you said it has.
- Branden
Re: Closures and default lexical-scope for subs
At 01:15 PM 2/15/01 -0500, John Porter wrote: my $a, $b, $c;# only $a is lexically scoped RTFM. Quite. But on a tangent, I see no good reason why this shouldn't be given the same interpretation as "my ($a, $b, $c)" on the grounds that functions taking list arguments that omit their parentheses swallow up the following list. And if the retort is, "my isn't a function," then I would like to know what it really is and why it's listed in perlfunc along with other things that aren't functions. If that's not enough controversy I can also ask about things which are labelled as both functions and operators :-) -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
At 04:38 PM 2/15/2001 -0300, Branden wrote: Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I've skipped pretty much all this thread so far, but I do need to point out that perl isn't targeted at beginning programmers, or beginning perl programmers. It's targeted at experienced programmers. If you learn a language you're a beginner once, and for a little while, but you end up experienced for a much longer time. Perl has lots of stuff that'll trip up beginners. That's OK. People are clever, and they can learn. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Closures and default lexical-scope for subs
Branden wrote: Take PHP and Python, for example. O.k., that's two out of the three modern languages. That's "most". Sorry, I stand corrected. Silly beginner gotchas. It's not an inconsistency of the language by any means. Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... Well, you proposed adding AWTDI, *and* breaking one of Perl's (few?) consistencies. Naturally, I oppose both measures. This introduces far more serious problems than it purports to solve. Tell me one. I couldn't find it. You named one yourself, but claimed that it would be "worth it" for some (well, one) programming contexts. Wrong! Read again: O.k. YAWTDI. Just what we need. Note that `outer $x, $y, $z' is the same as `outer($x, $y, $z)' in contrast to `outer($x), $y, $z'. Great. You want to break this one very consistent aspect of perl. print $x, $y, $z; "my" is a declaration, and it has higher precedence than comma. I don't see a problem. print() is not comparable. use strict 'vars' + my is already more than sufficient to this need. Sufficient? Yes. The best way? Maybe, maybe not. The only way? (So long,) Yes. I think TSBMTOWTDI. "...but I hesitate to make ten ways to do it." Furthermore it is arguable (as we're demonstrating :-) that the proposed way is any better.Perhaps if perl had no precedent in this area, it would be something to consider. As it is, it really isn't, because use strict 'var's + my is sufficient -- and not only sufficient, but brilliant. I truly believe this other TWTDI is being proposed -- if you'll pardon me -- mainly for the sake of grandstanding. I also see no action at a distance here, since the only way to change ... assuming `our' *outside* the block would affect variables inside the Hey! You are changing the meaning of what I said!!! I didn't write that! I didn't intend to change the meaning. I was just severely snipping what didn't need repeating. : I also see no action at a distance here, since the only way to change the : way a sub sees a variable is inside the sub the variable is being used. : That's where I think the discussion about RFC 64 was problematic. It was : assuming `our' *outside* the block would affect variables inside the : block. : And that's AAAD for sure! I never said `our' should affect the variables inside the block! Well, I don't know what happened here. All I did was cut out some lines. I did not (at least not intentionally) twiddle the meaning of your (or anyone else's) words. I'm only asking if it has the ``far more serious problems than it purports to solve'' you said it has. Please go back and read all the threads I referred to in my previous post. In a nutshell, I agree with the naysayers. -- John Porter You can't keep Perl6 Perl5.
Re: Closures and default lexical-scope for subs
Take PHP and Python, for example. my $a, $b, $c;# only $a is lexically scoped RTFM. my ($a) = FHANDLE; # after deducing (by the above) . . . # when I wanted only the first line. Silly beginner gotchas. It's not an inconsistency of the language by any means. Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I agree. I hate these gotchas. They cost a *lot* of problems when I'm trying to explain things. Tell me one. I couldn't find it. The main problem I see is cross checking. I *like* having to declare things as 'my' - it catches my errors for me: my $variable; $varaible = 1; # mis-spelled - caught by 'use strict'. If you had this 'use scope' pragma, this auto-error checking would be compromised severely. However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: my $a, $b; which is particularly insidious because $a and $b are default globals. Yuck. As should: my ($a) = STDIN; I'm also fond of making 'use strict' and '-w' ON by default, and turned off by pragma. But that's just me. Is there a 'annoying beginner mistakes and what the $!#$@ to do about them RFC'? If not, it might be a worthwhile thing to put together. Ed
Re: Closures and default lexical-scope for subs
Dan Sugalski [EMAIL PROTECTED] wrote: At 04:38 PM 2/15/2001 -0300, Branden wrote: Yeah. Beginners. I was one too. And I remember always falling on these... But that's OK, since we probably don't want any new Perl programmers... I've skipped pretty much all this thread so far, but I do need to point out that perl isn't targeted at beginning programmers, or beginning perl programmers. It's targeted at experienced programmers. If you learn a language you're a beginner once, and for a little while, but you end up experienced for a much longer time. eloquent... clever... clear... true... clap clap clap Perl has lots of stuff that'll trip up beginners. That's OK. People are clever, and they can learn. The same things can be said for any language. Even VB (it takes a while to get used to the bugs). However, many of the things that trip up beginners in other languages, including VB, aren't present in Perl. One of Perl's primary beauties IMO is that it is appropriate to all levels of programmer. Most other languages have a few bell shapes in their learning curve, with the largest at the front. Perl seems to be a steady incline with a teensy little tea bell at the front, which comprises mostly of the most important less of all -- common to all languages -- the grand principle of RTFM. Other than that, once you get past the "modem noise" shock, it's all basic programming theory (if, unless, while, do, sub). My hope for Perl 6 is that it doesn't break that with non-optional fluff. p
Re: Closures and default lexical-scope for subs
Peter Scott wrote:
At 01:15 PM 2/15/01 -0500, John Porter wrote:
my $a, $b, $c;# only $a is lexically scoped
Quite. But on a tangent, I see no good reason why this shouldn't be given
the same interpretation as "my ($a, $b, $c)" on the grounds that functions
taking list arguments that omit their parentheses swallow up the following
list. And if the retort is, "my isn't a function," then I would like to
know what it really is and why it's listed in perlfunc along with other
things that aren't functions.
I agree with this statement. Perhaps someone who was around during the
initial 'my' discussions can shed some light on why it binds so tightly.
I have observed you can do something like this:
my $OUTER = '';
if ( $some_value ) {
# 'my' only on the first one
(my $inner, $OUTER) = split;
# more code that uses $inner ...
}
if ( $OUTER ) {
# $inner not here, but that's fine...
}
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
Also, as the author of RFC 64, let me say that while I think it's cute
and nifty, I think it's also true from the discussions that it causes
far more problems than it solves. I no longer think it's a good idea, at
least not in its current incantation. There may be other ways to
approach it, but I can't think of any that aren't more complex than (a
possibly modified) "my".
-Nate
Re: Closures and default lexical-scope for subs
Edward Peschko wrote: Tell me one. I couldn't find it. The main problem I see is cross checking. I *like* having to declare things as 'my' - it catches my errors for me: my $variable; $varaible = 1; # mis-spelled - caught by 'use strict'. Still would be able to do it with `use strict'. My proposal isn't going to replace it! As it didn't replace the default global variables! As I said, I don't want you to use it or even like it, I'm only wanting YAWTDI. If you had this 'use scope' pragma, this auto-error checking would be compromised severely. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: my $a, $b; OK. Fine to me. Under `use strict' it actually would be already an error. I'm also fond of making 'use strict' and '-w' ON by default, and turned off by pragma. But that's just me. I'm fond of having an alternative to it, ie. `use scope'. I don't want it by default, as I don't want it to replace `strict' either. It would only be there for anyone decide if he would or wouldn't use it. As to turn on by default, I actually don't think making one of this things default would be good, because it would make one-liners and small quick and dirty scripts some harder to write. For longer scripts and modules (that already are many lines long), writing one or two more lines isn't expensive at all... - Branden
Re: Closures and default lexical-scope for subs
"Peter" == Peter Scott [EMAIL PROTECTED] writes: Peter Quite. But on a tangent, I see no good reason why this shouldn't be Peter given the same interpretation as "my ($a, $b, $c)" on the grounds that Peter functions taking list arguments that omit their parentheses swallow up Peter the following list. *some* functions. localtime doesn't. my is a unary function, prototyped vaguely as (\$) or (\@) or (\%). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Closures and default lexical-scope for subs
Branden wrote: If you had this 'use scope' pragma, this auto-error checking would be compromised severely. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). Except that only applies to un-declared variables, which currently (and hopefully forever) can only be global variables. -- John Porter
Re: Closures and default lexical-scope for subs
John Porter wrote: Branden wrote: Well, I checked the archives, and I found that the discussion begun in http:[EMAIL PROTECTED]/msg01441.html That thread was rather tame; even so, I believe the end result, if one can be deduced, is that the proposal is not a good one. There was more heated discussion in the thread rooted at http://www.mail-archive.com/perl6-language@perl.org/msg01089.html the discussion of RFC 16. Well, actually, I read that, and it pretty much discusses making `strict' default or not (which I believe is not), but I saw nothing against another pragma like the one proposed in RFC 64. I actually didn't see one thing that's a flaw in what I'm proposing. If you're seeing one, please tell me! I know it pretty much can have flaws, but I'm not seeing them. OTOH, I'm not saying it's perfect. Of course not! It may have some advantages over `strict' (it's more succint) the same way `strict' has advantages over it (error checking, more disciplined, more possibility to define scopes). Again, I'm not proposing ending with `strict', neither making it a default. It's only YAWTDI. Is there a problem with that? I know that "...but I hesitate to make ten ways to do it." As there's only two, it would be three, so I think we have still seven to find ;-) Once more, I don't ask you to use it or like it. I just think we could allow others to use it and like it (I would). Thanks, - Branden
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:49:44AM -0800, Randal L. Schwartz wrote: "Peter" == Peter Scott [EMAIL PROTECTED] writes: Peter Quite. But on a tangent, I see no good reason why this shouldn't be Peter given the same interpretation as "my ($a, $b, $c)" on the grounds that Peter functions taking list arguments that omit their parentheses swallow up Peter the following list. *some* functions. localtime doesn't. my is a unary function, prototyped vaguely as (\$) or (\@) or (\%). If my() would be an unary function, how come that my ($foo, $bar); makes $bar a lexical variable? my just isn't a function. Just like return or while aren't, even when followed by parenthesis. They are language constructs. Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
I agree with this statement. Perhaps someone who was around during the
initial 'my' discussions can shed some light on why it binds so tightly.
I have observed you can do something like this:
my $OUTER = '';
if ( $some_value ) {
# 'my' only on the first one
(my $inner, $OUTER) = split;
# more code that uses $inner ...
}
if ( $OUTER ) {
# $inner not here, but that's fine...
}
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Abigail
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 10:44:24AM -0800, Peter Scott wrote: Quite. But on a tangent, I see no good reason why this shouldn't be given the same interpretation as "my ($a, $b, $c)" on the grounds that functions taking list arguments that omit their parentheses swallow up the following list. And if the retort is, "my isn't a function," then I would like to know what it really is and why it's listed in perlfunc along with other things that aren't functions. my is language construct. Just like if, while and return that can be followed by parenthesis, but aren't functions. If that's not enough controversy I can also ask about things which are labelled as both functions and operators :-) Functions and operators are the same. It's just that what is labelled an operator usually takes a fixed number of arguments, often consists of non-alphanumerical characters and unlike what's labelled a function, is often not prefix. But that's only syntactic sugar (and vinegar due to precedence tables). Abigail
Re: Closures and default lexical-scope for subs
Still would be able to do it with `use strict'. My proposal isn't going to replace it! As it didn't replace the default global variables! As I said, I don't want you to use it or even like it, I'm only wanting YAWTDI. Right, but your approach isn't going to help in the cases where it is needed most, ie: long programs where it *is* nice to have lexical variables. There are two possibilities here: 1 - long scripts where you need lexicals 2 - short scripts where you don't. In #1, 'use scope' is going to hinder more than help, for the reasons that I mentioned. In #2, 'use scope' is not needed because you simply don't have strict on. Actually, I think sometimes it can be done with -w (``Variable xyz used only once, probably spelling error''). Right, but what of cases when you are consistantly using the wrong variable. Or you use it wrong twice. If its not bulletproof, I'd rather not rely on it. I'm fond of having an alternative to it, ie. `use scope'. I don't want it by default, as I don't want it to replace `strict' either. It would only be there for anyone decide if he would or wouldn't use it. The question is whether or not the pragma is worth the extra complexity in the parser/implementation that it would add as opposed to the benefit of its being there. If it was not that difficult to implement, I wouldn't mind seeing it.. As to turn on by default, I actually don't think making one of this things default would be good, because it would make one-liners and small quick and dirty scripts some harder to write. For longer scripts and modules (that already are many lines long), writing one or two more lines isn't expensive at all... well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. The main rationale behind this is that - face it '-w' is pretty much useless now for any module that includes other modules. Why? because you get those warnings as well as your own. Even the standard distribution of perl isn't free of this behaviour. Make them the default, and people will adhere to them. And '-w' will become useful again. And as newbies, they will also get feedback on things that used to be silent and hence learn faster. Ed
Re: Closures and default lexical-scope for subs
Branden wrote: There was more heated discussion in the thread rooted at http://www.mail-archive.com/perl6-language@perl.org/msg01089.html the discussion of RFC 16. Well, actually, I read that, and it pretty much discusses making `strict' default or not (which I believe is not), but I saw nothing against another pragma like the one proposed in RFC 64. You're focusing too narrowly on your specific proposal. In talking about other proposals, those threads make a lot of points which are relevant to yours. IOW, you're missing the spirit of it. "...but I hesitate to make ten ways to do it." As there's only two, it would be three, so I think we have still seven to find ;-) Again, you're missing the spirit of the aphorism (perhaps intentionally). We should be very careful when considering adding more WTDI, particularly if those WTDI are not necessary, as in this case. Once more, I don't ask you to use it or like it. That's the umpteenth time you've said that, but you seem to be trying to counter something I never said. I'm arguing against your proposal because I think it's a bad idea and is bad for perl. I assure you if it goes in, I will not use it. You don't need to worry about that. -- John Porter Ann wenno haddum billizac...
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" Beautiful. then just co-opt it. Right now when I say: #!/usr/local/bin/perl -e in a file i get Can't emulate -e on #! line at a.p. Either that, or add '-q' as a file version for '-e'. And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. Seems simple enough to me. Ed
Re: Closures and default lexical-scope for subs
At 12:43 PM 2/15/01 -0800, Edward Peschko wrote: On Thu, Feb 15, 2001 at 02:40:52PM -0600, Jonathan Scott Duff wrote: On Thu, Feb 15, 2001 at 12:25:44PM -0800, Edward Peschko wrote: well, I was thinking about this - there really should be an extra switch that makes this possible, rather than typing 'no strict; no warn;' ie: #!/usr/local/bin/perl -q # for quick and dirty. We already have a switch that means "quick and dirty", it's called "-e" Beautiful. then just co-opt it. Right now when I say: #!/usr/local/bin/perl -e in a file i get Can't emulate -e on #! line at a.p. Either that, or add '-q' as a file version for '-e'. And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., http:[EMAIL PROTECTED]/msg00025.html Better get the asbestos underwear ready. -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' thanks. 'no warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., http:[EMAIL PROTECTED]/msg00025.html Well, I agree with pretty much everything you said, except I like '-q' better than '-z' for aesthetic reasons. So... what was the rationale against it? Ed
Re: Closures and default lexical-scope for subs
At 01:03 PM 2/15/01 -0800, Edward Peschko wrote: http:[EMAIL PROTECTED]/msg00025.html Well, I agree with pretty much everything you said, except I like '-q' better than '-z' for aesthetic reasons. So... what was the rationale against it? Best read the archives... I am the wrong person to ask for a statement of the opposing viewpoint... -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
Peter Scott wrote: And in any case, make '-e' have the additional connotation that implies 'no strict', and 'no warn'. no 'warnings' Seems simple enough to me. Yes, that's what I thought; but this has generated more heat than light, at least on the times I've brought it up, e.g., Please, let's not retrace this argument. It's really become apparent to me that there's two types of folks on this: 1) the quick and dirty users / utility scripters 2) the instructors and massive code maintainers (Depending on your project at the time, you may switch between roles). The former vehemently support "RFC 16: Keep default Perl free of constraints such as warnings and strict", under various mantras from "Make things easy" to "Hey, one liners!" The latter vehemently support the concept of "use strict" and "use warnings" being on by default. The justification is that it helps people write cleaner code, catch errors faster, etc, and all you have to do is say "my" in front of all your variables. (However, let's not forget about strict refs!) I personally think that this is something Larry is going to have to decide. However, I would like to note that leaving these off by default lowers the transition curve to Perl 6 immensely for those people that use Perl as a glue/scripting/sysadmin language. Key: Not everyone becomes a Perl expert. Many people never leave novice/intermediate level. This doesn't mean that we should design the language for these people, but it also doesn't mean we should thumb our noses at them. -Nate
Re: Closures and default lexical-scope for subs
So... what was the rationale against it? Best read the archives... I am the wrong person to ask for a statement of the opposing viewpoint... hey... I'm a lazy guy.. ;-) So - I guess coming from someone who holds the opposing viewpoint, what was it? Ed
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Hmm. Nathan's example of my is in void context
Abigail's are not.
As there appears to be a way to tell them apart, is it possible (sane?) to
make both work? Or at least issue warnings (not mandatory, but defaulting
to on unless you have some sort of no warnings) for Nathan's case?
[where () round all three would make it do what he meant]
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
Abigail
Re: Closures and default lexical-scope for subs
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
well, I'd say no. How many people are going to run into this and have it not
do what they expect as opposed to:
my $a, $b, $c;
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Ed
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 02:03:21PM -0800, Edward Peschko wrote:
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
well, I'd say no. How many people are going to run into this and have it not
do what they expect as opposed to:
my $a, $b, $c;
The point isn't how many are going to run into this.
The point is how to determine when to warn or when not to warn.
It was suggested to DWIM when I use my in void context, and not when
my isn't used in void context. With the above example, such a rule
would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
to explain, very hard to bugtrack and totally unexpected. Even if not
everyone uses it.
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Both of the above my()s are in void context.
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
$c becomes 10. Should $c become 3 when my is placed before $a?
Abigail
Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
[resent to perl6-language, sorry for any duplicates] Edward Peschko wrote: I personally think that this is something Larry is going to have to decide. However, I would like to note that leaving these off by default lowers the transition curve to Perl 6 immensely for those people that use Perl as a glue/scripting/sysadmin language. Right, but what I don't understand is that its two extra characters at the end of a command line... whats the big deal about typing '-q' on one line in scripts? Its easy enough to advertise '-q' and put it in big lights... Yes and no, I think. As Alan Burlinson pointed out earlier, this is *not* a purely clean-slate we have here to work with. There are lots and lots and lots of users who know how Perl works. Many of these users don't even know that you can do this: my $x = 5; Let alone that this: my $x, $y, $z; Doesn't DWIM, again according to what most people think. Key: Not everyone becomes a Perl expert. Many people never leave novice/intermediate level. This doesn't mean that we should design the language for these people, but it also doesn't mean we should thumb our noses at them. So - why is it a religious issue then? I respect the fact that you want to write scripts without 'use strict'. I do this all the time. But I really think that its a small price to pay to put '-q' on the #!/usr/bin/perl command line for the vast benefits that it would give us all as far as CPAN goes. Let's separate the CPAN thing out for a moment. "use strict" and "use warnings" are not the universal solutions to CPAN quality issues, at least as far as I'm aware. 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. So - in the place of a '-q', would you support a mechanism for making sure that CPAN is '-w' clean? If so, how would you enforce it? Absolutely, 100%. But this is a separate issue. For example, a big problem with CPAN is also packaging. There's lots of modules that don't use the h2xs/Makefile.PL approach. 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. If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check for the packaging to make sure that "perl -MCPAN -e shell" will install the stuff cleanly. If there's simple problems (misnamed tar files, a $VERSION split onto multiple lines), we can even auto-fix this. Then send all the results to the user who uploaded the module. Heck, I'd even volunteer to head up a project to do this. But I think it's a separate issue from "use strict" and "use warnings", let's not confuse the two. -Nate
Re: Closures and default lexical-scope for subs
It was suggested to DWIM when I use my in void context, and not when
my isn't used in void context. With the above example, such a rule
would mean '$bar1' is my()ed, and '$bar2' isn't. That's IMO, very hard
to explain, very hard to bugtrack and totally unexpected. Even if not
everyone uses it.
well, for the small fraction of people that use it, they probably are
experienced and know to use parens to disambiguate. That's what I do when
I come across something totally unexpected. 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.
Anyways, I think this problem goes away if we adopt a suggestion that I
make below.
However, I think that:
my $a, $b, $c;
and
my $a, $b, $c = @_;
Hmm. then I have a misunderstanding of what exactly 'void' context is. 'void'
context to me is when you say
$a, $b, $c;
ie: when something is not the lhs of an '='.
should work the same and they wouldn't do so if 'void' context was the only
criteria used.
Both of the above my()s are in void context.
well, then it works then. cool.
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
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);
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)
my $a = STDIN # DWIM
my $a, $b, $c.
As for your examples:
GetOptions (foo = \(my $foo), bar = \(my $bar))
tie (my $shoe) = $string;
both of these look easier to follow to me, at least.
$c becomes 10. Should $c become 3 when my is placed before $a?
No, I think in both cases, they should produce '3'.
ok, now back to:
(my $foo1, $bar1) = (my $foo2, $bar2) = ('foo', 'bar');
Works as expected. $foo1, $bar1, $foo2, $bar2 are all 'my'ed.
Ed
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thu, Feb 15, 2001 at 03:02:10PM -0800, Nathan Wiger wrote: If we're interested in increased CPAN quality, there's a bunch of stuff we can do. See also, CPANTS (totally vaporware, but its a plan) http:[EMAIL PROTECTED]/msg00148.html Heck, I'd even volunteer to head up a project to do this. Don't say that too loud, I might just take you up on it.
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote: Also, if I have: @a = (1 .. 10); $a, $b, $c = @_; 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); Do you mean: (($a, $b), $c) = (($d, $e), $f); perhaps? 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) So, the cost of leaving off parens at some places, is to add them elsewhere? What's the point? In the long run, you aren't gaining anything, all you are doing is messing up the precedence table. It's already complicated enough, why have a different precendence table in perl6? Fine, you might not need the parens for my(), you suddenly need them where you don't need them in perl5. my $a = STDIN # DWIM my $a, $b, $c. As for your examples: GetOptions (foo = \(my $foo), bar = \(my $bar)) tie (my $shoe) = $string; Not enough arguments for tie... This trap is documented. both of these look easier to follow to me, at least. You're kidding, right? If I wanted LISP, I know where to find it. $c becomes 10. Should $c become 3 when my is placed before $a? No, I think in both cases, they should produce '3'. Ah, more pointless changes with perl5. I think I've seen enough of perl6 by now. I'll treasure my copy of perl5 till the end of times. Abigail
Re: Closures and default lexical-scope for subs
At 09:01 PM 2/15/01 +0100, [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2001 at 11:08:47AM -0800, Edward Peschko wrote: However, that still doesn't get rid of the gotchas - personally I think that: my $a, $b, $c; should be an error, a warning, or DWIM. Especially: Personally, I don't think so. GetOptions (foo = \my $foo, bar = \my $bar); and tie my $shoe = $tring; are just way too practical to suddenly require more hoops. I don't want to DWIM this. Would it be so bad to have to type GetOptions (foo = \my ($foo), bar = \my $bar); tie my ($shoe) = $tring; if we made 'my' consistent with all other functions that take lists (yes-I-know-it's-not-a-function)? -- Peter Scott Pacific Systems Design Technologies
Re: Closures and default lexical-scope for subs
On Thu, Feb 15, 2001 at 10:29:33PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 08:19:27PM +, Nicholas Clark wrote:
On Thu, Feb 15, 2001 at 09:05:55PM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 11:23:10AM -0800, Nathan Wiger wrote:
But I have never found a situation where this is so useful to justify
the other problems it creates. However, there may well be true technical
reasons why "my $x, $y, $z" does not do what many think it should.
As I wrote elsewhere, other reasons not to change the behaviour of my:
GetOptions (foo = \my $foo,
bar = \my $bar);
tie my $shoe = $tring;
Hmm. Nathan's example of my is in void context
Abigail's are not.
As there appears to be a way to tell them apart, is it possible (sane?) to
make both work? Or at least issue warnings (not mandatory, but defaulting
to on unless you have some sort of no warnings) for Nathan's case?
[where () round all three would make it do what he meant]
If I have:
(my $foo1, $bar1) = (my $foo2, $bar2) = ("foo", "bar");
then '(my $foo1, $bar1)' is in void context, while '(my $foo2, $bar2)'
isn't.
Do you really want them to behave differently?
No. But I couldn't think of anything like that, which was why I asked.
best way to shoot down my suggestion is an example where existing behaviour
can't be determined from void/scalar/list context.
Will the above do?
Yes, thanks.
I would *not* like to teach why the they behaved differently.
Nicholas Clark
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thu, Feb 15, 2001 at 02:54:37PM -0800, Nathan Wiger wrote: Edward Peschko wrote: Right, but what I don't understand is that its two extra characters at the end of a command line... whats the big deal about typing '-q' on one line in scripts? Its easy enough to advertise '-q' and put it in big lights... Yes and no, I think. As Alan Burlinson pointed out earlier, this is *not* a purely clean-slate we have here to work with. There are lots and lots and lots of users who know how Perl works. Many of these users don't even know that you can do this: my $x = 5; Let alone that this: my $x, $y, $z; right, but that's a pretty small issue. For one, my *would* be more well known if perl had a default stricter policy. And preventing pain is a simple matter of people knowing that '-q' exists and advertising that fact. You could even put the message in the output for the error as an upgrade note: Global symbol "$ca" requires explicit package name at aa line 2. Execution of aa aborted due to compilation errors. --- 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, as in: #!/usr/local/bin/perl -q (although ultimately the error checking can help quite a bit in tracking down errors. see 'use strict' and 'use warning' in the manual.) --- I think that notes like these tied to the executable are going to be big helpers in migrating people up in general. And my guess is that there are going to be a lot bigger issues than this to face for upgrading people. my $x, $y, $z; Doesn't DWIM, again according to what most people think. It would DWIM if I had my druthers. write scripts without 'use strict'. I do this all the time. But I really think that its a small price to pay to put '-q' on the #!/usr/bin/perl command line for the vast benefits that it would give us all as far as CPAN goes. Let's separate the CPAN thing out for a moment. "use strict" and "use warnings" are not the universal solutions to CPAN quality issues, at least as far as I'm aware. No of course not the 'end all be all'. But they are a large, large, large part of it. Its proactive thinking versus reactive thinking. It forces module writers to *have* a warnings policy and a strict policy. How many times have I wanted to put 'use strict' in a module and forgotten about it? How many times have I wanted to use '-w' but was not able to because of all the junk that comes out of it? Too many to count... Make it by default and a large portion of the problem is solved. 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. well, take the two possible cases: 1) With -e, you have no extra characters to type. 2) With -q, you have two extra characters to type. If you get really used to -q, then it rolls off the fingertips: '/usr/local/bin/perl -q'. And in the rare case that you forget '-q', you'll get instant feedback from all the errors that you get. Now take the opposite case. That you forget 'use strict'. In this case, you can - and I have - looked at it for hours to find the errors that I missed. And worse yet, these are runtime errors. And then I realize that I meant 'use strict' and typically whack my head a couple of times. So - in the place of a '-q', would you support a mechanism for making sure that CPAN is '-w' clean? If so, how would you enforce it? Absolutely, 100%. But this is a separate issue. For example, a big problem with CPAN is also packaging. There's lots of modules that don't use the h2xs/Makefile.PL approach. 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. of course, but they will fix a large part of them. You'd be amazed how many errors will be caught with 'use strict' and 'use warnings'... If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check But we don't want to check for '-w' and 'use strict'. We want to leave that up to the module owner. All I want is a clear policy towards warnings and strict. Thats a hell of a lot easier to achieve with something proactive. As for '-T', well, some modules don't *want* to be run in '-T' mode. The 'installable' part is intriguing, but then again there are problems with feedback - do you allow a module to be uploaded if it doesn't compile against system b, and c but works flawlessly for a,d,e,
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
On Thursday 15 February 2001 19:21, Edward Peschko wrote: How many times have I wanted to put 'use strict' in a module and forgotten about it? Then it isn't, technically, a perl problem. How many times have I wanted to use '-w' but was not able to because of all the junk that comes out of it? That also, technically, isn't a perl problem. Make it by default and a large portion of the problem is solved. Define "large portion" and "the problem." If you get really used to -q, then it rolls off the fingertips: '/usr/local/bin/perl -q'. If you really get used to "use strict;", then it rolls off the fingertips, too. of course, but they will fix a large part of them. You'd be amazed how many errors will be caught with 'use strict' and 'use warnings'... You'd be amazed how many errors *aren't* caught with strict and warnings. If we're interested in increased CPAN quality, there's a bunch of stuff we can do. We can have a standard test suite that's run against every module uploaded to check if it's installable and compiles basically. We can check for -w, -T, use strict, and tons of other stuff. We can check But we don't want to check for '-w' and 'use strict'. We want to leave that up to the module owner. All I want is a clear policy towards warnings and strict. Thats a hell of a lot easier to achieve with something proactive. What can be more proactive than "Your code should work."? As for '-T', well, some modules don't *want* to be run in '-T' mode. Why not? Evvery module should handle untainted data, just in case, right? That is potentially far more dangerous than using a global in the wrong package, no? In my experience, its always been the proactive policies which work the best. Reactive policies have lots of shortcomings and are hard to set up. Which is easier to do - prevent a fire or put one out after its started? Well, speaking from experience, put one out. There are an unbelievable number of ways a fire can start, a lot of them unforeseeable. But most fires themselves fall into a half-dozen classes, with fairly standard firefighting techniques. And the more I think about it, you cannot make the project you describe proactive - ie: we will not accept your module *until* conditions x,y,z occur - this would be too onerous to accept for module developers. So you want to force people to adhere to strict rules, but it would be too onerous to force them to adhere to strict rules? (Personally, I don't care about the extra warnings, as long as I can shut them up. That doesn't really change perl's behavior. Forced strictness does.) -- Bryan C. Warnock bwarnock@(gtemail.net|capita.com)
Re: Closures and default lexical-scope for subs
On Fri, Feb 16, 2001 at 12:32:01AM +0100, [EMAIL PROTECTED] wrote:
On Thu, Feb 15, 2001 at 03:07:51PM -0800, Edward Peschko wrote:
Also, if I have:
@a = (1 .. 10);
$a, $b, $c = @_;
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);
Do you mean:
(($a, $b), $c) = (($d, $e), $f);
perhaps?
No, actually not. I mean to add the parens by determination of
'list operators', things like '='. I would discourage ',' in its use
as a statement separator, and replace it with ';'. And I'd like
to be able to say:
while ($content = $collector; length($content))
{
}
or even
while { $content = $collector; return(length($content)) }
{
}
although that does look sort of funky.
So, the cost of leaving off parens at some places, is to add them elsewhere?
What's the point? In the long run, you aren't gaining anything, all you
are doing is messing up the precedence table. It's already complicated
enough, why have a different precendence table in perl6? Fine, you might
not need the parens for my(), you suddenly need them where you don't need
them in perl5.
Well, I just analyzed this empirically. I went through a rather large module
(libwww) to analyze how much impact the changes that I'd propose would make,
in a real-life setting, and how many parens you would lose/gain in-toto:
The pattern:
my(...) = @_;
appears 116 times.
The pattern:
($x1,$y1,$z1) = ($x2, $y2, $z2);
or
while (($a1,$b1) = each (%suffixType))
appears approx 25 times.
With just these two types of items you could lose 143 pairs of parenthesis
minimum. Add on extra sundry things, and you lose 50 more paren pairs. If you
went for broke, you could probably lose lots more than this
Now, as for the things this breaks:
There were 3 things that broke outright, all statements that were:
while ($content = $collector, length $$content) {
Additionally, there were some statements that looked like:
$VERSION = sprintf("%d.%02d", q$Revision: 1.16 $ =~ /(\d+)\.(\d+)/);
which I don't think break because the operator in question (=~) only
works against scalars..
So that's 3 statements out of 9000 lines of code. But then again, I only did
a rough analysis, you are welcome to check it over.
tie (my $shoe) = $string;
Not enough arguments for tie...
This trap is documented.
I guess then I don't understand what:
tie my $shoe = $string
is supposed to do... I count either one or two arguments here, depending
on how I parse it.
both of these look easier to follow to me, at least.
You're kidding, right? If I wanted LISP, I know where to find it.
no, I'm not. And anyways, this solution is far less lispish than what
you are suggesting:
my $a, $b, $c = @_
vs
my ($a, $b, $c) = @_;
while $key, $value = each %hash
vs
while ($key, $value = each %hash)
vs
while (($key, $value) = each %hash)
I think I've seen enough of perl6 by now. I'll treasure my copy of perl5
till the end of times.
you are welcome to do that. Its called 'use perl5' at the top of your
script.
Ed
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
I guess this was what was meant by 'put your asbestos gloves on'.
On Thu, Feb 15, 2001 at 07:57:31PM -0500, Bryan C. Warnock wrote:
On Thursday 15 February 2001 19:21, Edward Peschko wrote:
How many times have I wanted to put 'use strict' in a module and
forgotten
about it?
Then it isn't, technically, a perl problem.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
How many times have I wanted to use '-w' but was not able to because
of all the junk that comes out of it?
That also, technically, isn't a perl problem.
Yes, its a perl usability problem. It comes down to how easy perl is to use.
Make it by default and a large portion of the problem is solved.
Define "large portion" and "the problem."
The problem is stability/usability of modules on CPAN. The 'large portion'
of problems is the errors caused by people not using '-w' and 'strict' on their
modules causing run-time errors.
If you get really used to -q, then it rolls off the fingertips:
'/usr/local/bin/perl -q'.
If you really get used to "use strict;", then it rolls off the fingertips,
too.
yeah, but I covered this down below. If you forget '-q' it isn't that big
a deal, its easily found. If you forget 'use strict'
ANYWAYS, READ MY POST AGAIN ABOUT WHAT HAPPENS IF YOU FORGET 'USE STRICT'
BEFORE YOU SAY SOMETHING LIKE THIS.
You'd be amazed how many errors *aren't* caught with strict and warnings.
This is irrelevant. I never said it would fix the world.
What can be more proactive than "Your code should work."?
Its the enforceablity of that concept.
What I'm saying is that if you *really* want a revolution, try to force people
to only be able to release their modules *until* it works on a large number
of platforms. If you used that as a criteria, perl itself would never get out
the door. ( witness the number of bug reports on perl5-porters )
As for '-T', well, some modules don't *want* to be run in '-T' mode.
Why not? Evvery module should handle untainted data, just in
case, right?
well, no, actually. Some modules evaluate code given on the command line, and
are quite useful. And regular expressions can take - as an argument -
unevaluated code through ?{}.
That is potentially far more dangerous than using a global in the wrong
package, no?
That's why -T exists. You can turn it on if you are going to be using it in
suid scripts, and boom, it gives you a list of errors.
But the point is that sometimes things that are taint-unsafe are useful. And
hence you can't use a blanket evaluation mechanism, it has to be done case
by case.
In my experience, its always been the proactive policies which work the
best.
Reactive policies have lots of shortcomings and are hard to set up. Which
is
easier to do - prevent a fire or put one out after its started?
Well, speaking from experience, put one out. There are an unbelievable
number of ways a fire can start, a lot of them unforeseeable. But most
fires themselves fall into a half-dozen classes, with fairly standard
firefighting techniques.
ok, let me put it another way - why start fires just so you can put them out?
And the more I think about it, you cannot make the project you describe
proactive - ie: we will not accept your module *until* conditions x,y,z
occur - this would be too onerous to accept for module developers.
So you want to force people to adhere to strict rules, but it would be too
onerous to force them to adhere to strict rules?
I think that there is a basic misconception here - there is NO FORCING GOING
ON. The only thing I'm 'forcing' people to do is come up with a policy towards
warnings or strictness. Who am I to say a module writer if he/she wants to put
'no strict; no warnings' in his/her module?
The fact is, though, that people will get used to the extra safety blanket that
these two things give, and I bet people will use it 75% of the time if not more.
And we'll all be better off.
And anyways, yeah, there's a big differnce between a use strict policy, and
making a module work on 20 different platforms before it can be published.
The manpower might not be available. the equipment might not be available. The
module owner might not WANT to port his module to multiple platforms. And so
on and so on and so on.
(Personally, I don't care about the extra warnings, as long as I can shut
them up. That doesn't really change perl's behavior. Forced strictness
does.)
Exactly. You can shut them up with 'no warnings' or '-q'. There is no such thing
as 'forced strictness', that's a straw dog that's unfortunately relatively
easy to beat.
Ed
Closures and default lexical-scope for subs
I expect Perl 6 will have some way to define its variables as being
lexical-scoped in the sub they are used as default, either by the language
default, or by a pragma, as `use scope "subs"; ', as it's proposed in RFC
64.
If that's the case, I wonder how closures will be done, since having
lexical-scope in every sub would mean that variables inside closures would
automatically be lexical, being different from the ones in the sub that made
the closure.
sub foo {
$bar = 1;
$closure = sub {
return $bar++;
};
return $closure;
}
The problem is that $bar inside the closure is different of the one in
`foo', because it's lexically scoped to the sub it's in, which is the
closure. The code above would actually compile to
sub foo {
my $bar = 1;
my $closure = sub {
my $bar;
return $bar++;
};
return $closure;
}
One naive way to solve this would be saying `only named subs will define a
lexical-scope for its variables', but that isn't right if you consider that
anonymous subs can be named, as
*foo = sub {
$bar = 1; # not lexically scoped???
...
Of course typeglobs will probably go away, but I doubt naming an anonymous
sub will be cut of the language, since it's used by many modules that build
classes (Class::*, I'm not sure which of them do it... Someone can give some
examples?).
Well, my suggestion for solving the problem is creating a new keyword of the
my/our/your/their/his/... family that would explicitly `import' the variable
from the parent sub. Of course this would be a compile time thing (e.g. like
my), so that it would only tell the compiler that it should do the right
thing to that name access the parent sub's variable.
sub foo {
$bar = 1;
$closure = sub {
parent_sub's $bar;
return $bar++;
};
return $closure;
}
Of course `parent_sub's' sucks! But I have no better idea. Any suggestions?
I see a slightly conceptual advantage in having a keyword to indicate the
closure, because the variable is actually stored together with the sub
reference somehow, and having a keyword to indicate that would make it
explicit.
References:
* see the way Python does it, it's explicit but it's rather clumsy. In
Python, you must declare a parameter variable with some name, and set its
initial value as the outer variable's value. It kind of does the same thing
that this above, but uses initialised parameters to do this, what is rather
confusing.
In http://www.python.org/doc/current/ref/function.html :
# Return a function that returns its argument incremented by 'n'
def make_incrementer(n):
def increment(x, n=n):
return x+n
return increment
add1 = make_incrementer(1)
print add1(3) # This prints '4'
Perl 5 would be:
sub make_incrementer {
my $n = shift;
my $increment = sub {
my $x = shift;
return $x + $n;
};
return $increment;
}
Perl 6 with parent_sub's (please give me a better name!) and
lexically-scoped variables by default:
use scope 'subs';
sub make_incrementer {
$n = shift;
$increment = sub {
$x = shift;
parent_sub's $x;
return $x + $n;
};
return $increment;
}
Comments?
- Branden
Re: Closures and default lexical-scope for subs
Branden foobar wrote: I expect Perl 6 will have some way to define its variables as being lexical-scoped in the sub they are used as default, either by the language default, or by a pragma, as `use scope "subs"; ', as it's proposed in RFC 64. If that's the case, I wonder how closures will be done, since having lexical-scope in every sub would mean that variables inside closures would automatically be lexical, being different from the ones in the sub that made the closure. Well, since the former isn't going to happen, the latter isn't going to be a problem. my suggestion for solving the problem is creating a new keyword of the my/our/your/their/his/... family that would explicitly `import' the variable from the parent sub. Ugh - upvar? No thanks. I see a slightly conceptual advantage in having a keyword to indicate the closure, because the variable is actually stored together with the sub reference somehow, and having a keyword to indicate that would make it explicit. Why should it be explicit? What ambiguity needs to be cleared up? I like the fact that perl handles the grotty details for me. -- John Porter You can't keep Perl6 Perl5.
