Re: Warnings, strict, and CPAN

On Fri, Feb 16, 2001 at 10:13:07PM -0500, [email protected] wrote:
> On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote:
> > On Fri, Feb 16, 2001 at 08:41:02PM -0500, [email protected] wrote:
> > > On Fri, Feb 16, 2001 at 03:28:36PM -0800, Edward Peschko wrote:
> > > > Its because '-w' is a global switch.
> > > 
> > > What about the new lexical warnings?  "use warnings"?
> > 
> > umm... that's part of what this is all about. People don't have a policy 
> > towards warnings, which makes '-w' useless.
> > 
> > I *want* a global switch. I want the ability to never have to forget to type
> > 'use warnings' in a package and track it down for hour upon hour. Or 'use
> > strict'.
> 
> Hold it a moment.
> 
> You find -w useless because it has global effect.
> But you don't like warnings.pm because it *doesn't* have global effect.

yes, '-w' is useless right now because it has global effect. When people are 
forced either to think about the problem or put 'no warnings' in each of their
modules, it will have value again.

> If I understand what you're saying, you think -w will become useful
> again if warnings are on by default because module authors will have
> more incentive to eliminate them?  Human nature says it will just be
> an incentive for those same authors to say "no warnings".  This just
> covers up the problem.

yeah, in some way it covers up the problem, but it lets me go about 
MY BUSINESS. It lets me bugproof my modules, and stops me from tearing out my 
hair when I am compiling my programs and forget to type 'use warnings' or 
'use strict' at the beginning of my script. And it serves as a documentation 
for an existing problem. 

I'm beginning to think there should be an extra flag that turns *on* warnings
even if 'no warnings' is explicitly stated. This is the 'enable me to help you
out' flag. That way, it would be a lot easier for me as a module consumer help
find bugs in things that the module writer himself doesn't have a grip over.

That's the way that '-w' is right now. But I only feel like helping people when
I'm in a charitable mood - I don't feel like doing it every bloody time.

Again - there's a point that you really have NOT answered, and I wish you would.
It is *easy* to find a non-existant '-q' in your script if you are expecting 
it to be there and it isn't.

It is one hell of a burden to find a missing 'use strict' or 'use warnings'.
'Well, type them then' you say. Right, and always type ';' at each line, or 1;
at the end of each file. Its as unavoidable as a *syntax error*, which is the 
point. syntax errors should be easy to fix, not hour-long treks through code.

You say that people will simply cover up their tracks with 'use warnings'. 
Maybe. Maybe not. But as sure as hell is hot, there is going to be one place
where this is not the case - the standard distribution. That should be a *big
push* - making it so warnings coming out of the standard distribution are 
readable.

Right now, I do a search on the standard distribution, and I see 
'use warnings::register' in 13 out of 270 modules. Make 'use warnings' the 
default, and you'd bet that there would be a big push to make the standard
distribution clean.

After all, Its an *embarrassment* to say 'use 'use strict' and '-w'' to 
everybody, and not to do it yourself. We need to eat our own dog-chow if we
expect to tell anybody what's a good thing to do.

> As I understand it the reasons why it would be a good idea to turn
> strict and warnings on by default are:
> 
> 1. so you won't forget to turn it on
> 2. to save a little typing
> 3. to make people more aware of the decision to turn it off

I'd say #2 is more akin to avoiding syntax errors in your programs. Again, 
forgetting to type 'use strict' in your script and 'use warnings' is a syntax
error to me.

Add: 
  4. to make '-w' usable again
  5. to make the perl6 group put its 'money where its mouth is' and bulletproof
     the perl distribution.
  6. to eventually wean newbies off of '-q'.

#6 is important - right now, I get punished for forgetting to type 'use strict'
and 'use warnings' to the tune of hours. I search through my code for logic
bugs, etc.

Now take your average newbie. Every once in a while, he is going to forget to
type '-q'. What's going to happen? His screen is going to get filled with
syntax errors that he never had before.

So, he's going to 1) add '-q' to his script - moments after this occurs or 2)
he's going to go into those errors, and try to fix them.

If he does #1, well then he's cost himself maybe 5 seconds of time and a bit
of annoyance. (as opposed to my hours)

If he does #2, well, he's on the road to figuring out that 'use strict' is a 
good thing!

So say he goes for #2. And then he starts running the program, and these 
warnings things come up. Now again, he either puts '-q' in his program, or he
continues to debug it. If he continues to debug it, then great! he finds out
how good warnings are.

Now contrast that to the situation today. Developers sometimes go through 
*years* without learning about 'strict' or warnings. Why should they? The only
thing a book says to them is a lukewarm 'use strict' and 'use -w' - there's no
incentive, they never see first hand what it can offer them.

They go through the perl experience in the darkness. And finally they either
get sick of blundering onto the same mistake over and over again, and start 
looking it up in the manual or they grow old and die not knowing that they
could have saved months off their lives if they had just used features that
was hidden in a manual somewhere.

I wish to *god* warnings and strict had been on by default when I first started
perl. I too would have probably saved months upon months of effort, and lord 
knows how many late nerve-wracking nights I would have avoided. I would have
stumbled onto their benefits a lot faster.

> But if they have -q and if Perl is too verbose by default, they'll
> just shut it off to shut it up, defeating #3.  They're not thinking
> "yes, I realize this is dangerous to not have warnings on" they're
> thinking "god, what's all this crap on my screen?!"

They will do that the first time. And maybe the #100th. But one time, they
won't. And that one time will come a lot faster if they are looking at it,
interactively, as opposed to having the power of 'use strict' and '-w' stuck
in the closet..

> > There is lots more wriggling room than people think.
> 
> Do you know how long FreeBSD distributed perl4 as /usr/bin/perl?  I
> think it was only in 1998 they switched to perl5.  FOUR YEARS after
> 5.000 came out.  Why?  They didn't want to break their user's
> programs.

that's irrelevent because of perl's 'use perl5' feature. God I love that idea.

> The more we break compatibility, the longer acceptance will be
> delayed.  We should not break it without good reason.  Those which
> have been presented are not good enough reasons.

that is not true. And in any case, you should not be the judge of whether or not
it is true. You said that a large percentage of perl programmers want 
'use strict' and 'use warnings' on by default; their voices should be heard by
Larry. The RFC that you started should be finished, only if to give him the
rationale on both sides of the argument.

> > It isn't. Like I said, I want to have a global. I want to be able to
> > *boom* turn on warnings and strict and have it blanket cover my code. 
> > I can't do that with the current situation. And this is
> > fundamentally broken now.
> 
> PERL5OPT='-w -Mstrict'
> 
> or
> 
> PERL5OPT='-Mwarnings -Mstrict'

THAT DOES NOT WORK. First of all, your syntax is off - the '-Mw..-Ms..' one
will ignore the '-Mstrict' part and generate an error because -M can only 
take one argument. But more importantly, THIS IS NOT UNIVERSAL AND CANNOT WORK
IN A UNIVERSAL SCOPE. 

Try the following code out if you don't believe me.

--A.pm--
package A;

$ab = 1;
$a = undef;
print $a;

--a--
use A;

$ab = 2; 
$a = undef;
print "HERE!!! :$a:\n";

Now see exactly how many errors/warnings slip through with 
'PERL5OPT=-Mstrict':

A.pm line 2 ($ab = 1) slips through.

Now see exactly how many error/warnings slip through with 'PERL5OPT='-Mwarnings'

A.pm line 4 (print $a) slips through.


Why? Because - contrary to popular opinion - -M does not put a 'use module'
at the beginning of every file or every package, it puts a 'use module' at the 
beginning of YOUR SCRIPT ONLY.

Think about it a bit - It *can't* do the obvious thing of putting 'use module'
at the beginning of every file. Why? for the very same reason that we
are talking about - it would break most of the modules out there. It could
step over variables or functions (by exporting things) 

So the only thing that '-Mstrict' *can* do is force you to have strict at
the beginning of your script. Which is hardly a solution at all. We hashed this
out on the perl5 mailing list about a year and a half ago, and we were stuck
in the same rut. Everyone has to play by the rules or no one can. 

And by enforcing a policy that you *need* strictness and warnings, or 
explicitly saying that you don't, you can get around this.

And in any case, what if it was true? What if you could find a 'magic, do it
all PERL5OPT argument that solves the problems discussed (which is very doubtful
for the reasons mentioned, but lets imagine for a bit.) 

Well, you'd have to take that sucker from machine to machine, from platform
to platform, from box to box. Sort of like the hell I'm going through in taking 
my intelligent tcsh defaults from place to place.

> No it isn't???  I ASSURE you from many experiences, changing a program
> from unstrict to strict is NOT a simple task and typing C<use strict>
> is the absolute LEAST of my worries.

Its a non-trivial thing, yes, but that's what 'use perl5' is for. So people
have time for upgrading.

> But the net effect will be worse!  Consider, currently there's
> three options:
> 
> 1. You leave warnings off.  Not good, but its quiet.
> 2. If you use C<use warnings> you only get your problems.
> 3. With -w you get everyone's warnings.
> 
> Now, I don't find #3 to be much of a problem.  Most modules don't
> produce spurious warnings unless they're in early alpha.  If something
> does spit out lots of warnings, I'm glad to know it because it
> indicates either a mistake on my part in using the module or a low
> quality module.  My solution?  Fix my code or fix the module.
> Anything else is just sweeping the problem under the carpet.

Sometimes you want to just get things done. Sometimes you want to do what you
expect and go out and help someone. That should not be the default.
In any case, it sure as hell dilutes your quality and the quickness of finding
YOUR bugs.

And it is not 'sweeping the problem under the carpet' if we coopt '-w' to 
FORCES warnings to be displayed, even if 'no warnings' is in effect. (And yes,
I know you said this can't be done, but read on).

The order of debugging would then be:

a) fix your modules
b) fix other peoples modules.

In any case, its a problem that has an easily engineered solution. And doubly 
in any case, it would help the standard distribution become warning free.

> Now, if warnings & strict are default...
> 
> 1. You use -q.  Not good, but its quiet.
> 2. You say C<use warnings> and you only get your own problems.
> 3. You use -w and you STILL only get your own problems!

But I get my own problems in all my modules, scripts, everything by using '-w'.
Not just the scope in question.  I want a way to sift my problems away from
other people's problems. I'd like to change '-w' so its meaning becomes look
for *anybody*s problems, not just my own.

> Why?  Because everyone's got a "warning policy" (ie. C<no warnings>).
> The net effect is you can no longer see potential problems inside 3rd
> party software and there's no way to turn warnings back on that code
> except through editing the source.  Result?  More time spent trying to
> figure out what the hell is wrong.

Like I said, this is assuming two things:

	1) that everybody is going to use 'no warnings' (which I doubt). I still
           think for reasons given above, that there will be a positive effect
           here by turning warnings on by default.

	2) that you can't engineer a solution in the form of a flag. 

> Your warning policy encourages sweeping problems, not just under the
> carpet, but into the ocean!

No it doesn't. See above. And in any case I can't see how the current situation
could be any worse than it already is.

> And no, -w should not override C<no warnings> else you'll have
> legitimate cases of warning suppression being violated.  (See
> AnyLoader, Cwd, ExtUtils::MM_Unix, Fatal, etc... for examples).

Well, '-w' really isn't needed under the new scheme so I don't see why not.
There could be a 'no warnings (I really mean it) extension.'.  

And I don't see why someone would say:

	no warnings::I_really_mean_it

when they could say:

	no warnings;

and get the benefit of people running -w and debugging their programs for them.

As for impact of this new I_really_mean_it pragma, well when I count *my* 
particular CPAN subset (128 MB worth of the most popular perl modules) I get 
just 11 lines with 'no warnings' (outside the regression-test for warnings). 
They are

./perl-5.6.0/ext/File/Glob/Glob.pm:             no warnings;
./perl-5.6.0/lib/Cwd.pm:                        no warnings;        
./perl-5.6.0/lib/English.pm:                    no warnings;
./perl-5.6.0/lib/ExtUtils/MM_Unix.pm:           no warnings;
./perl-5.6.0/lib/ExtUtils/Manifest.pm:          no warnings;
./perl-5.6.0/lib/Fatal.pm:                      no warnings; 
./perl-5.6.0/lib/File/Glob.pm:                  no warnings;
./perl-5.6.0/lib/Math/BigFloat.pm:              no warnings; 
./perl-5.6.0/lib/Text/ParseWords.pm:            no warnings;
./perl-5.6.0/lib/utf8_heavy.pl:                 no warnings;

./mod_perl-1.24/lib/Apache/PerlRun.pm:          no warnings;

Note there is *one* legitimate line outside of the standard distribution. One!

As for the string 'use warnings' in OR outside the perl distribution, well 
there are *no* uses. At all.

So there is no big upgrade issue and all that you are saying is, while it has
to be accounted for, not a big deal in the end. If you want my list of modules
for double checking, you are welcome to them.

You see, IMO think you really had the right idea before and were convinced too
easy (probably got shouted down). And in any case Larry should know 
the arguments both ways.  I think that the RFC should be revived and 
bulletproofed. 

I'd also like to, when that RFC is done, post it to the 'perl6-language' 
newsgroup for further comment. Or post it here; however, I would like to 
bulletproof it versus whatever the 'opposition at large' has to say and they
may not be reading this newsgroup.

Ed