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: 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: 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: 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: 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: 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: 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
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: 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: 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: 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
