Re: Warnings, strict, and CPAN

Its because '-w' is a global switch. To wit:

--AA.pm--

my $a = undef;
print $a;


--a.p--

use AA;

my $a = undef;
print $a;


If you run this, it will print:

Use of uninitialized value in print at AA.pm line 5.
Use of uninitialized value in print at a line 6.

So what happens when a 3rd party comes out with a module that doesn't
have a warnings policy?

I run my script, and get tons of *their* warnings, ones that may or may
not be helpful. And I shouldn't have to sift through their warnings
to see which ones are relevant and which ones are just the case of
sloppy programming.
Yes!
If you put a note in the script after each time an error comes up,
something like:

Global symbol "$ab" requires explicit package name at a line 5.
Execution of a aborted due to compilation errors.
----
NOTE - if you are seeing this error and wondering what the hell it means,
perl's policy towards errors has changed since perl5. It now
checks for declarations stronger than it did before. If you want
the old behaviour, use the '-q' switch. If you want to disable
these upgrade messages, do xxxx.

People will get the point pretty quick.
I don't understand what you are saying. Brushing my teeth won't help
me become rich, but it'll give me a tangible demonstratable benefit...
Think of it this way - you'd sell '-q' as 'training wheels' for your
bike. Something to soften the learning curve.
You are consciously deciding to work in a strict environment. You are
consciously deciding not to use the '-q' switch.
Well, not many languages provide you with training wheels...
well, like I said what's the big bloody deal about typing 2 extra
letters? I mean *come on*. Is it a badge of shame? Is it the computer
equivalent of a scarlet A? So frickin' what - *hell*. ITS NOT THAT BIG
A DEAL.

And anyways, in another post I offered to have an extra flag that
indicates warning/strictness, and to have strict+warnings by default
in modules. That'd satisfy me, because it would solve the main problem
that I see on CPAN.

Although that's truly a shame though. Lots of people who don't know
that strict + warnings are your friends and will save you tons and tons
of time will never go into them because they won't bother to play around
with them...

But that's their issue, not mine. So, yes, that would satisfy me, if
warnings and strictness were on by default in modules.
No, as far as I know we will be able to put 'use perl5' up on top of
their scripts, and they will convert over in their leisure.

And if some people choose to keep 'use perl5' up top, that's fine.
Although I'd say that I don't want to see their warnings by default.
No it doesn't. Like I said, they will use it - hopefully later on they
will discard it. It provides an easier upgrade path because it makes
people type *less* and it puts strict and warnings up front
See up above. The policy towards warnings and strict is default positive,
and takes an action to become negative. In my experience, people focus
on the default behaviour.
Again, see up top. '-w' is a global flag, and hence you get thousands
of global warnings.
the point is that the notes would come at the bottom of every single
compilation. They would point out - by example - exactly where perl5
and perl6 differ. if we do what I'm suggesting, and turn

$a, $b, $c = $d, $e, $f;

into

($a, $b, $c) = ($d, $e, $f);

then code that looks like:

($a = $b, $d);

would generate a warning:

WARNING: scalar assignment to a list. NOTE - this has changed since perl5
$a = $b, $d now parses as ($a = ($b, $d))!
That's the point - I do turn on strict 95% of the time. 5% I forget to
type it. And it causes me hours of heartache.

However, if a '-q' switch existed, and someone forgot to type it, they
would get instant feedback. And hence what this is saying is that
their couple of extra seconds to type -q and not deal with warnings is
worth my hours of suffering, and the hours of suffering that people
garner from errors that otherwise would be caught, and yet make it to
CPAN.
I disagree. Like I said, I think a compromise can be made - provide
strictness by default in modules, and non-strictness in scripts. That
satisfies me.
Right, but I'm not asking for a silver bullet. Maybe a silver slingshot,
or a BB gun. Making a language useful is the process of having several
small incremental improvements, not one big one.

Ed

What about the new lexical warnings? "use warnings"?

I thought this, too. In fact, its in that pseudo RFC I posted way
back when as a rationale. After some observation of how people deal
with strict, warnings, tests, etc... I really don't think there's any
conscious decision there unless the person has already internalized
the concepts.

In the same way that I unconsciously type '-wle' in all my one-liners,
people will write '-q'.

No, people will just shut it off pretty quick. This gains nothing.

But if you're advocating new programmers should shut perl up, why have
it on by default?! Just to save a little typing?

Trust me, having to type '-q' will not mean people will think about
it. They'll just say "gee, that's annoying" and type it in. Lead a
horse to water, etc...

Come to think of it, what language or popular compiler does have
run-time (not compile-time) warnings on by default?

You'd be amazed at the sort of excuses people will use to avoid
upgrading. The fairly innocent "foo@bar.com" to "foo\@bar.com"
incompatibility has kept many companies down at perl4 even still
today!

Ok, saving ten characters of typing per file is not a valid reason to
do anything, so nix that.

The upgrade path is made no easier by having to delete "-q" than
having to type "use strict". That's totally swamped by the code sweep
necessary when turning strict on in a formerly unstrict program.

There is no win here. People will shut it off without thinking.

I think this is covered by "use warnings".

This would be a very useful feature to have, but its FAR too verbose
for day-to-day usage. If you want to see a similar effect, try
developing your code with "use diagnostics" on ALL THE TIME.

Its useful, just not as the default.

Splitting the language is extremely dangerous, but we're covering that
in a different thread.


Here's something that came up in earlier discussions that stopped me
dead. Many people like to shut off warnings when they ship code. I'm
not going to argue the wisdom of this here, but there are valid
business reasons to not want end-users to see warnings.

So if warnings are on by default, how do you shut them off? You
either must edit the code as part of the build/distribution process or
provide a wrapper program which runs it under -q. This assumes you
even *have* a build process. Many (most?) places don't.

In order to ship code with warnings off you must

1 - have a build process (not a simple task)
2 - edit the code automatically.

#1 is hard enough. Its desireable, but still very difficult (mostly
political and social reasons in any size organization). But #2... I
really, really, really don't want to require anyone to have to
automate the editing of Perl code.

Not if we bury the documentation for -q somewhere devilishly difficult to
find... like perlrun. That'll pretty much guarantee that 25% of the
posters to clpm won't find it in their lifetimes.
I absolutely disagree with outputting that message. It defeats the purpose
and trains people to use -q without thinking why.
Er, Perl is loose enough that those run-time warnings substitute for only a
part of the kind of strictness checking that other languages do at compile
time.
Darwinian selection in action. But if you want P6 to be so backwards
compatible that the largest issues are smaller than "@", an awful lot of
good stuff ain't gonna make it in, it seems to me. 'Sides, we already got
some clues that P6 won't have to be that backwards compatible with P5.
But why force all the new programs which haven't been developed yet which
will be developed faster and be maintained better if they do get
strictified to be consigned to the same bugginess?

I repeatedly tell people, "If you're handed a program that doesn't have
-w/use strict in it, hand it back and say, Please insert -w/use strict, and
give it back to me when you've eliminated all the resulting messages," and
many of those people have thanked me for that instruction. So far,
no-one's said it was a bad idea.
Okay, we'll make it so the only way to shut it off is by providing the
answer to an exercise picked at random from Knuth. No, wait, they'll just
end up pasting the answers in from a cheat sheet posted on the net, scratch
that...
I don't get this. If someone's developing code right now with "use
warnings", and they want to ship with warnings disabled, they gotta edit
the code anyway. How is commenting out "use warnings" at release time
different from inserting "no warnings" at release time?

And if they're developing the code all the way through without warnings (in
which case they don't deserve to have customers), then they'll just put "no
warnings" or -q in there from the start and there's no release editing
required.

Not quite the point. I'm looking for an analogous situation so we can
use the result as something of a case-study.

Perl 6 is going to break things, fine. But break them for a better
reason than saving a few keystrokes, please.

That's fine if people know why. Some people don't. Some people know
why and decide otherwise. Complicate it by the fact that its no
longer a human rejecting your perfectly valid code, but a computer.
People will resent it.

You also have to take into account the legions of sysadmins who use
Perl as more powerful shell scripting. Do not equate not using strict
and warnings with "newbie".

They're not using the warnings pragma, they're mostly using -w when
its run and tested. Alternatively, you can set PERL5OPT='-w' on your
development machines (though I haven't heard of this in wide
practice).


Code style is a very, very emotional and personal issue. Adding any
default enforcement is going to piss off lots and lots of people.
Just look at how much discussion this topic has generated all over the
lists! What's the net gain? Some vague ideas about making people
more aware of warnings and saving a few keystrokes.


Instead, let's concentrate on some more tangible areas of need. Perl
is almost completely lacking in code metric tools. We have no
statistical analysis tools, our coverage library is barely there and
our two profiling tools are anemic and underdocumented. Our lint
checker is an early alpha. CPAN has no security checks, no author
signatures, little auditing. Vast sections of perl's core libraries
and source code are not covered by tests, etc...

S'not about saving keystrokes, as many times as I do type the same things
in every file; it's about giving newbies the right introduction to the
language and providing appropriate feedback at the appropriate level of
individual development.
strict/warnings are not that picky; the odds that the code is more wrong
than right are very good if they complain. "But it produces the right
answer" is not a defence. You know that; why else would you develop with
them? Anyone who resents the feedback is in the wrong business.
Okay, but these people are not going to be put out by sticking -q on the #!
line.
Eh? I still don't get it. You're saying that instead of typing 'foo',
these people are typing 'perl -w foo' every time, to save themselves from
putting -w on the #! line? That's insane.
I don't find the ideas vague... and they could save clpm from descending
into a cesspool of iniquity. Oops, too late...
All agreed, and orthogonal. So you concede the point, eh? :-)

You're making it sound like -w is a personal tutor!

No, they're not in the wrong business, they're just learning. "But it
produces the right answer" may not be a valid defense, but it is a
common one and you and I aren't going to be around to tell them it
isn't. Forcing extra stricness on a new programmer only works if
there's a mentor around to help them through the process and explain
things.

We're talking about the folks who call things 'ls' instead of 'dir'
because its one less character to type, right?

Perhaps, but its common.

Yes, but like it or not, they have over 10 years of precedent behind
them. We're used to this situation, the screaming has already been
done, the scabs are healed over. Let's not pick at them.

Help me out here. You're saying:

User: perl -e 'print 1/$x'
Perl: Illegal division by zero at -e line 1
User: Okay, run-time error, no problemo, I can handle that.

User: perl -we 'print 1/$x'
Perl: Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value in division (/) at -e line 1.
User: Okay, that's it, if you're going to whine like that I'm
switching to Ruby.
Oh well, then we should call the new executable 'p' instead of 'perl'.

I checked... it's not taken...
I've always picked at 'em... in any case, the mandate for Perl 6 design was
to consider everything fair game, within user-defined reason. We may well
eliminate bareword filehandles in Perl 6, just 'cos they no longer make
sense; seems we might as well go for everything we want to fix. If we
don't create a better language when we have the chance, someone outside of
Perl will do it and name it after a snake or something...

<snip>

User: perl -w myprogram.pl
Perl: Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value in division (/) at myprogram.pl line 5.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.
Use of uninitialized value at myprogram.pl line 10.
Use of uninitialized value at myprogram.pl line 11.
Use of uninitialized value at myprogram.pl line 13.

Newbies don't write one-liners. Newbies tend to write their programs
in one big chunk and then try to run it. Faced with a daunting list
like that (that represents a badly written loop) a lone newbie might
become discouraged. However, their program might run Just Fine.

I don't know which is worse, not seeing the warnings or being flooded
with them. Neither is good, though. But having warnings on by
default we're just trading one for the other.

Don't laugh, I've seen people do even more rediculous shell aliasing
for similar results.

Yes, but its questionable which one is "better". Given a fresh start
writing a new language, I'd definately say warnings by default. I'd
also say arrays should start at one, not zero. But we've got a large
and diverse community to deal with.

This is very much a 6.0 of one, 12.0/2.0 of another type of situation.

Okay, I think we should agree to disagree at this point and back away from
the keyboards... I've made my best arguments and I hate reruns. By now
everyone knows what we both think and they're probably sick of it to boot.

I could go for this...

perl -we '$h{$_} = 1 for @a'
It looks like you don't understand hash slices. Would you like a brief
explanation of how they work?
That sounded to me like "yes". Examples of hash slices:...

And if they're running PerlTk, it pops up a little paper clip saying all
this stuff.

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'.
Fine - let them do that.

Yes it does. It tells them about '-q' in a way that they don't have to
be searching through it in the manual.
Fine, let them think its annoying. They might think this for a while, and
then think *why* the '-q' is there, etc. etc. etc.
So what? perl5 isn't fundamentally broken is it? I'm assuming CPAN is still
going to work off of perl5...

Most likely, the way the upgrade is going to work is incrementally. RedHat,
ActiveState, Debian, etc. will silently upgrade their distributions to perl6.
There is lots more wriggling room than people think.
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.
no it isn't. again this is going to be pretty minor compared to the rest of the
changes that perl6 is going to have over perl5. There are two possibilities:

1) that perl6 is going to look so much like perl5 that it won't matter
2) that perl6 is going to have some fundamental improvements that
inherently break backwards compatibility.

Personally, I'm hoping for #2.
I don't think so... Anyways,
No it isn't - '-w' is a global flag for a *reason*. If everybody had a
warnings policy, it would become useful again.
So what? let them do it. As it stands, they have to do this anyways - either
remove '-w' from their scripts, or remove 'use warnings' from their modules.

The only case where they would not have to do this is if they *never* used
warnings in the first place. In which case, they could add 'no warnings' to
the top of their scripts, although I don't vouch for the veracity of their
code.

They have to do this anyways. This is a smoke and mirrors argument.
And in any case, I'm not very sympathetic. 'We can't provide people a
consistent, strong warning strategy because some people might find it harder
to release shoddy code.'

Ed

(ps -- as for the modules/scripts thingy... well, I guess I disagree with the
dichotomy part, but I could see where that would be a tough sell. ah well...)

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.

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.

But that defeats the purpose of turning strict on by default!!! If
they're not thinking about it, there's no point!

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

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?!"

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.

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.

PERL5OPT='-w -Mstrict'

or

PERL5OPT='-Mwarnings -Mstrict'

Ta da.

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.

Have a look at this patch which turned on strict in everything I could
in the core libraries. File::DosGlob is a good example of one of the
more difficult changes.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-12/msg00212.html

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.

Anyhow, point is there's a choice.

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!

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.

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

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).

As I think I already pointed out to Peter, its usually the case that
-w is on the command line and in their test programs.

Came up when I tried this earlier. I drew the line between -e and not -e.

I do not agree with this argument of Edward's.
Just a sec. If someone shipped a module with 'no warnings', then either
they had a good reason for doing so, and we should respect it and not be
bothered by it, or they don't know what they're doing and we shouldn't be
using their code. More likely the latter.

Right now, if I wanted to impose strictness on third-party modules, I'd
have to edit the source to insert the 'use strict' that no-one seems to
bother putting in a .pm. Hmph. Maybe I should be doing that, it might help.

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.
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.
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.
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..
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.
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.
Its a non-trivial thing, yes, but that's what 'use perl5' is for. So people
have time for upgrading.
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.
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.
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.
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.
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

I think we're rapidly approaching "agree to disagree" territory here.

No, there will probably be a big push to shut it off, based on
historical reactions to this sort of thing.

If you don't think so, I urge you to submit a patch to p5p which turns
on C<use warnings> in every core module. Consider it a trial run.

I'm not disagreeing that the core libraries need shaping up (just look
at my patching record). But this is not the way to do it.

YMMV wildly. Again, I do not disagree with your opinion and hold
nearly the same myself, but you'll find fairly strong reactions
otherwise.

All right, where is this mysterious mass of low-quality code you're
working with? I stick -w on all programs by habit and I use *alot* of
CPAN code. I'm not overwhelmed with warnings.

No no no. FreeBSD's distribution might be able to audit its code and
add in C<use perl5>, but its user base cannot be expected to do so. A
distribution which includes perl will be very, very hesitant to
upgrade if that upgrade will break their user's existing code.

Larry reads the mailing lists, too. He's unfortunately already
probably read these same arguements a few times already.

Hmm, its damned silly that you can't give two modules on the command
line.

Anyhow, you don't want it to work in universal scope. I think we're
in agreement there.

I thought that was the problem you were having. Forgetting to type
"use strict" in your programs.

Modules? Modules should have test suites. A simple test would be to
check for /use strict/. Of course, you *are* writing test suites for
all your modules, right??

For your own development, sure. But that's your problem. Me? I have
a laptop that I use everywhere. :P

Otherwise, your program will run just fine with strict off. It'll
also run just fine with warnings off. No distribution worries.

That's not the point. Your original argument was that '-q' made for a
simpler upgrade path for turning on strictness because its easier to
delete two characters than to type ten. I say its a rediculous
optimization since the process of making a non-strict program strict
is extremely non-trivial.

If you're using their module, their bugs ARE your bugs! If
something's throwing warnings in your program, you fix it. Whether
you wrote that part of the code or not. Perl doesn't care who
authored what part, it'll make the mistakes just the same.

I don't want to have to turn on extra flags to see all the problems in
my system. You're just trading your having to remember to turn on
C<use strict> for my having to turn on some new flag.

??? which new scheme?

That's because warnings.pm is a 5.6.0 only thing and CPAN modules have
to work on older versions of perl. Try grepping for '\$\^W' instead.
Combining that with a search for "no warnings" brings us up to
19 .pm files (about 12% of the total number).

Checking my site_perl, I come up with 62 modules (again, about 12%)
that play with $^W.

Aside from the compatibility issues, most modules do not C<use
warnings> for the same reason people don't ship with -w on. We don't
want to give anyone trouble unless they ask for it. Which is fine.
This is not to say warnings are ignored. I run all my tests with -w.

Maybe I'm missing something; I'm sure the philosophy is for the standard
distribution to be -w clean, so shouldn't everything be equally okay with
use warnings?
???

$ perl -Mwarnings -Mstrict -le 'print keys %INC'
Exporter.pmCarp.pmstrict.pmwarnings.pm

Try it and see! I'm serious. It'll be an interesting experiment.

BTW The modules themselves might be -w clean, but the testing suite
certainly isn't!

Sorry, misspoke. That works. This does not:

PERL5OPT='-Mwarnings -Mstrict' perl -wle 'print keys %INC'
unkown warnings category '-Mstrict' at -e line 0
BEGIN failed--compilation aborted.

It seems to be parsing that as: C<use warnings '-Mstrict'>. IMHO this
is a bug.

Yes, MJD pointed it out last November in
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg01107.html.
Simon Cozens submitted a patch which failed the test; I think I found the
problem with it and just submitted a revised patch to p5p.

...and MJD and Jarkko and I worked on it and we put together something
which was OK.

Both Simon's and Peter's patches...
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg01131.html
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-02/msg00913.html

Fail mjd's (revised) test suite.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-11/msg01256.html

Fortunately, its the test suite that's wrong! :) Doncha love a happy
ending?

Here's the code patch against bleedperl along with a revised version
of mjd's suite. The revision of the test isn't quite complete. What
should really be done to prevent future mis-failures is compare
PERL5OPT switches vs those on the command line. Something like:

PERL5OPT='-Mstrict -w' ./perl -e 'print $::x'
./perl -Mstrict -w -e 'print $::x'

The proper way to write the test is to make sure both do the same thing.
But this is good enough for now.


--- t/run/runenv.t 2001/02/18 05:58:06 1.1
+++ t/run/runenv.t 2001/02/18 06:09:10
@@ -0,0 +1,137 @@
+#!./perl
+#
+# Tests for Perl run-time environment variable settings
+#
+# $PERL5OPT, $PERL5LIB, etc.
+
+BEGIN {
+ chdir 't' if -d 't';
+ @INC = '../lib';
+}
+
+my $STDOUT = './results-0';
+my $STDERR = './results-1';
+my $PERL = './perl';
+my $FAILURE_CODE = 119;
+
+print "1..9\n";
+
+# Run perl with specified environment and arguments returns a list.
+# First element is true iff Perl's stdout and stderr match the
+# supplied $stdout and $stderr argument strings exactly.
+# second element is an explanation of the failure
+sub runperl {
+ local *F;
+ my ($env, $args, $stdout, $stderr) = @_;
+
+ unshift @$args, '-I../lib';
+
+ $stdout = '' unless defined $stdout;
+ $stderr = '' unless defined $stderr;
+ my $pid = fork;
+ return (0, "Couldn't fork: $!") unless defined $pid; # failure
+ if ($pid) { # parent
+ my ($actual_stdout, $actual_stderr);
+ wait;
+ return (0, "Failure in child.\n") if ($?>>8) == $FAILURE_CODE;
+
+ open F, "< $STDOUT" or return (0, "Couldn't read $STDOUT file");
+ { local $/; $actual_stdout = <F> }
+ open F, "< $STDERR" or return (0, "Couldn't read $STDERR file");
+ { local $/; $actual_stderr = <F> }
+
+ if ($actual_stdout ne $stdout) {
+ return (0, "Stdout mismatch: expected [$stdout], saw [$actual_stdout]");
+ } elsif ($actual_stderr ne $stderr) {
+ return (0, "Stderr mismatch: expected [$stderr], saw [$actual_stderr]");
+ } else {
+ return 1; # success
+ }
+ } else { # child
+ for my $k (keys %$env) {
+ $ENV{$k} = $env->{$k};
+ }
+ open STDOUT, "> $STDOUT" or exit $FAILURE_CODE;
+ open STDERR, "> $STDERR" or it_didnt_work();
+ { exec $PERL, @$args }
+ it_didnt_work();
+ }
+}
+
+
+sub it_didnt_work {
+ print STDOUT "IWHCWJIHCI\cNHJWCJQWKJQJWCQW\n";
+ exit $FAILURE_CODE;
+}
+
+sub try {
+ my $testno = shift;
+ my ($success, $reason) = runperl(@_);
+ if ($success) {
+ print "ok $testno\n";
+ } else {
+ $reason =~ s/\n/\\n/g;
+ print "not ok $testno # $reason\n";
+ }
+}
+
+# PERL5OPT Command-line options (switches). Switches in
+# this variable are taken as if they were on
+# every Perl command line. Only the -[DIMUdmw]
+# switches are allowed. When running taint
+# checks (because the program was running setuid
+# or setgid, or the -T switch was used), this
+# variable is ignored. If PERL5OPT begins with
+# -T, tainting will be enabled, and any
+# subsequent options ignored.
+
+my $T = 1;
+try($T++, {PERL5OPT => '-w'}, ['-e', 'print $::x'],
+ "",
+ qq{Name "main::x" used only once: possible typo at -e line 1.\nUse of uninitialized value in print at -e line 1.\n});
+
+try($T++, {PERL5OPT => '-Mstrict'}, ['-e', 'print $::x'],
+ "", "");
+
+try($T++, {PERL5OPT => '-Mstrict'}, ['-e', 'print $x'],
+ "",
+ qq{Global symbol "\$x" requires explicit package name at -e line 1.\nExecution of -e aborted due to compilation errors.\n});
+
+# Fails in 5.6.0
+try($T++, {PERL5OPT => '-Mstrict -w'}, ['-e', 'print $x'],
+ "",
+ qq{Global symbol "\$x" requires explicit package name at -e line 1.\nExecution of -e aborted due to compilation errors.\n});
+
+# Fails in 5.6.0
+try($T++, {PERL5OPT => '-w -Mstrict'}, ['-e', 'print $::x'],
+ "",
+ <<ERROR
+Name "main::x" used only once: possible typo at -e line 1.
+Use of uninitialized value in print at -e line 1.
+ERROR
+ );
+
+# Fails in 5.6.0
+try($T++, {PERL5OPT => '-w -Mstrict'}, ['-e', 'print $::x'],
+ "",
+ <<ERROR
+Name "main::x" used only once: possible typo at -e line 1.
+Use of uninitialized value in print at -e line 1.
+ERROR
+ );
+
+try($T++, {PERL5OPT => '-MExporter'}, ['-e0'],
+ "",
+ "");
+
+# Fails in 5.6.0
+try($T++, {PERL5OPT => '-MExporter -MExporter'}, ['-e0'],
+ "",
+ "");
+
+try($T++, {PERL5OPT => '-Mstrict -Mwarnings'},
+ ['-e', 'print "ok" if $INC{"strict.pm"} and $INC{"warnings.pm"}'],
+ "ok",
+ "");
+
+print "# ", $T-1, " tests total.\n";
--- MANIFEST 2001/02/18 03:28:09 1.2
+++ MANIFEST 2001/02/18 06:00:15
@@ -1715,6 +1715,7 @@
t/pragma/warn/utf8 Tests for utf8.c for warnings.t
t/pragma/warn/util Tests for util.c for warnings.t
t/pragma/warnings.t See if warning controls work
+t/run/runenv.t Test if perl honors its environment variables.
taint.c Tainting code
thrdvar.h Per-thread variables
thread.h Threading header
--- perl.c 2001/02/18 05:32:53 1.1
+++ perl.c 2001/02/18 05:43:51
@@ -1173,6 +1173,7 @@
PL_tainting = TRUE;
else {
while (s && *s) {
+ char *d;
while (isSPACE(*s))
s++;
if (*s == '-') {
@@ -1180,11 +1181,18 @@
if (isSPACE(*s))
continue;
}
+ d = s;
if (!*s)
break;
if (!strchr("DIMUdmw", *s))
Perl_croak(aTHX_ "Illegal switch in PERL5OPT: -%c", *s);
- s = moreswitches(s);
+ while (++s && *s) {
+ if (isSPACE(*s)) {
+ *s++ = '\0';
+ break;
+ }
+ }
+ moreswitches(d);
}
}
}

Applied, thanks.

(Had to add run/*.t to the list of testables in t/TEST.)

I started trying it and hit something really weird... or maybe I've just
been working too many days in a row.

Why this difference depending on whether I reference a module with an
absolute path or a relative one?

[peter@tweety ~]$ /usr/bin/perl -wc /usr/lib/perl5/5.6.0/Shell.pm
/usr/lib/perl5/5.6.0/Shell.pm syntax OK

[peter@tweety ~]$ cd /usr/lib/perl5/5.6.0/

[peter@tweety 5.6.0]$ /usr/bin/perl -wc /usr/lib/perl5/5.6.0/Shell.pm
/usr/lib/perl5/5.6.0/Shell.pm syntax OK

[peter@tweety 5.6.0]$ /usr/bin/perl -wc Shell.pm
Name "Shell::capture_stderr" used only once: possible typo at Shell.pm line 3.
Shell.pm syntax OK

[peter@tweety 5.6.0]$ cd ..

[peter@tweety perl5]$ /usr/bin/perl -wc 5.6.0/Shell.pm
Name "Shell::capture_stderr" used only once: possible typo at
5.6.0/Shell.pm line 3.
5.6.0/Shell.pm syntax OK

Nothing up my sleeve:

[peter@tweety perl5]$ env | grep -i perl
PWD=/usr/lib/perl5
[peter@tweety perl5]$

Color me baffled. And it's not just that module, there are many that
exhibit this behavior, so it's something to do with perl -cw.

That's very, umm... interesting. Hmm. Post it to p5p, see what happens.

No -- its *anywhere* that you write scripts/modules/what have you. Anywhere
you miss it, it is a syntax error to me.
Of course - ultimately I write test suites. I however don't write test suites
when I'm first iterating code and design. Why the hell would you write a test
suite when your interface is changing?

That's where it is a syntax error. And that's where there is no good solution.
Look - if you are going to have a discussion with me, *please* answer all of
my points. I do this for you, you should show the same courtesy to me.
Otherwise, it is very frustrating. It is very easy to edit out points that you
don't have an answer for, and come back with an edited reply.

That's called hitting a straw-dog. You are caricaturing my position - perhaps
non-intentionally, but you are doing it nonetheless.

So go back to my original post. My argument is that it is going to be a process
of weaning people off of *not* using strict and warnings. And my point is that
people will start with '-q', and probably use it most of the time. But once in
a while, they will forget.

And when they do, they will either immediately add '-q' to their scripts and
ignore the warnings, or they will actually think about the errors that are
coming on their screens.

If they think about the errors, they will *see first hand* how warnings and
script help them. This is a lot better than having a lukewarm dictum of
'use strict' or 'use -w' thrown at them.

*please* read my entire posts and look at individual issues before responding.
Its very frustrating when you don't. If you don't agree with the above logic
tell me why. If you *do* then concede the point.
Right, but its a question of priority - by making warnings the default we force
ourselves to be more careful. We sure as hell can't tell people 'use -w' if we
don't believe it ourselves.

And its a question of *usability*. Look at the following piece of code:

use Carp;

my $a = undef;
carp($a);

When I run this under 'use warnings', I get the following.

Use of uninitialized value in join at /home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 164.
Use of uninitialized value in join at /home/edwardp/install/lib/perl5/5.6.0/Carp/Heavy.pm line 31.

Now what the $#%#@ is that supposed to mean? How is that going to help
beginners? Modules don't have to be '-w' clean by themselves, modules have to
be '-w *useful*'.

And this is going to involve to some extent making modules so they point
to the original source of failure, rather than point to themselves. So they
behave more like exceptions.
You don't. Since '-w' is no longer needed in its present meaning, you can turn
on '-w' to get its new meaning.
The new scheme where '-w' overrides 'no warnings'. Or perhaps 'hide warnings'
is a better term. Please read my post. If you don't understand something
tell me so and I'll try to explain it further.
It does not matter - if you came up with a term - 'hide warnings'
- that is more logical after all, and had '-w' override that term, there would
be no backwards compatibility issues.
Make it 'hide warnings', and put that in your modules then. And run your tests
with '-w'. In any case, its a way of putting strict and '-w' to the
foreground, by default, so that we HAVE to make it useful.

In any case, I want this put in an RFC. Larry may or may not read these posts
- and it does no harm whatsoever to formalize it. I sure haven't heard the above
arguments before...

Ed

I agree that strict is good. I agree that warnings are good. I agree
that I would impose this blessing on any project I'm involved with.

However, I will not try to enforce this on the world. Don't use a
language as a style hammer.

That's the last I'm saying on that subject. I'll agree to disagree.

I write my docs and tests in parallel with the code and change them as
my interface changes, though the interface typically doesn't change
radically since I think it through fairly well as a result of having
to write the docs. At the very least I have a test script which makes
sure the module compiles (in your case, it would check for strict).

print <<IRONY;
I consider a module without tests or documentation to be a syntax
error. Maybe perl should refuse to run a module without POD and
MakeMaker should refuse to install a module without tests unless given
a special flag. Then people will sometimes forget to use that flag
and they'll be reminded of the importance of writing documentation and
tests.
IRONY

Its a good idea to write docs and tests, but I'd never try to impose
my style on every Perl programmer.

Unfortunately at this point, they will probably be overwhelmed with
warnings and fixing their program to run clean will take a relatively
large effort. The benefit will not be clear, it'll just look like
lots of busy work.

The problem is, fixing errors (and warnings) should be an iterative
process. The way you expect -q to be used discourages this. There's
nothing worse than suddenly seeing a flood of warnings from your code.

We've already been around in circles on this. As above, I'll agree to
disagree.


Let's use this as a test case of the wonders of making warnings
default and the magical results it will have on cleaning up the perl
core libraries. You are aware of a bug, you're even rather annoyed by
it, and you're accutely aware of its existance due to a warning. But
you've done nothing about it.

Why haven't you fixed this? Why haven't you even reported this?! Why
isn't this a test case??

I'm sorry if this sounds like a personal attack, but its a perfect
illustration of how easily and often minor warnings are ignored and
how turning them on isn't going to make a dent in the community's
psychology towards minor warnings. Even you have the subconscious
attitude "oh, somebody else will fix it" (unfortunately, that somebody
is too often me, Perl's garbage man).

The fix, BTW, is simple. The warning points directly to the problem.
A minute spent examining Carp::Heavy shows all that's necessary is to
remove the assumption that @error is defined (this is the Carp::Heavy
from bleedperl).

- my $err = join '', @error;
+ my $err = @error ? join '', @error : 'undef';

And then to write a test to ensure it doesn't happen again.

If you're not willing to do it, why should you assume anyone else is?
I can't fix up the whole distribution alone.

Ed, you're your own counter-example. You'll find you're not the only
one, few people want to do this sort of work.


I'll stop the argument there, I think we've yelled at each other long
enough. Write up the RFC if you'd like, but I'd request that you
provide a pointer to this specific post. I think it most elegantly
sums up my objections.

hey look, all it is is a question of balance. Like it or not perl already
forces upon you a series of inconsistancies in syntax, misunderstandings,
special cases, weird characters, etc.

These *also* are constraints that make newbies tear their hair out - and both
'-w' and 'use strict' help *clear up* those things. Primarily they aren't
procedural things, they are switches that help deal with the *language itself*.

And yes, they should be made easy enough for newbies to learn. Probably easier
than they are now.

The things you mention are procedural. And as tempting as it is to enforce a
little vigor on procedure, I agree with you. I don't want to make a coding
architecture on by default..
Oho! Now we are getting somewhere. I never said that I want to keep warnings
as they currently are... They should be a hell of a lot more intuitive than
it is currently. And I agree with you that it has severe shortcomings as it
is currently designed.

I want to make it *simple* and *intuitive* enough so it can be turned on by
default. That is a pre-condition for them being added to as default.
But I don't think it is a bug - in perl, or in 'carp'. I think its a bug in
the person's code. And in the way warnings are handled. I'd want this to say:

Use of unitialized value passed to function 'carp' at line 4.
yeah, well 1) its not a personal attack, its an attack of an idea. And 2)
you are right, as warnings stand, it won't make a dent in the attitude towards
them.

As for the 'oh, somebody else will fix it', well that's what I'm trying to do
- distribute the load. It has to be workable, warnings have to be on by default
and there has to be *incentive* for people to fix them. Enough incentive that
they aren't turned off in large numbers.
But this is too verbose, and it is doing something that should be done by
default with warnings. If I pass a bad value to a function, the language should
be smart enough to warn me in the correct place without me doing anything.

And anyways, that's not simple enough. You'd have to say something like:

my $error = join('', map((defined($_))? $_ : 'undef', @_);

since any of the arguments could have undef values in them.
Like I said, that's the idea - turning on the defaults goes a ways towards
distributing the workload.

And part of this has to be making the warnings/strict process simpler to use
than it currently is or you may be right, people might bury their heads in the
sand.

And - btw - I too have done several fixes of this type, albeit on third party
modules. As for the 'error', well I picked it out of the air just to show how
easy it was to do. I didn't have to look long. :-(
well, I prefer the term 'vigorous debate', but, ok, I'll write one up, and
I'll point to this specific post in any way or shape you see fit, but I'd like
to hear your comments on it, point by point.

And I'd like to post it to 'perl6-language' rather than 'perl6-language-strict'.
Hell, we are talking primarily about *warnings* here, not strict.

Ed

The decision to write tests and docs is procedural and individual. So
is the decision to turn on strict and warnings. Both are good ideas.
Neither has a direct effect on how the code will be written (ok,
strict has minor effects). Neither should be inflicted on an
unsuspecting programmer without an experienced programmer to help them
through.

When documentation and tests are required and no guidance is given,
the docs will be worthless and the tests will be weak.

When strict and warnings are required and no guidance is given, the
restrictions will be worked around and the warnings will be quieted
without thought as to their origin.

Only with guidance and experience can these be have their desired
effects. Otherwise, its just so much bureaucracy.

God, I sound like the Tao of Programming.

Yes, this came up in much earlier conversations. Warnings must be
made more friendly and more accurate before they can be made default.

Its a noble endevour, but extremely difficult with widespread
consequences. Currently, at run-time, perl has access only to an
optimized op-code tree. It does not see the original code. This
leads to seemingly inaccurate warnings, but its just perl reporting on
its version of the code.

There is also the problem that you can't do too much run-time warning
analysis without slowing down the program! They're deliberately kept
down to the "if this then warn" type of warning.

Finally, run-time warnings can't be too smart. perl can't be warning
me every time I do a clever trick that it doesn't think is correct. I
don't want to have to be writing C<{ no warnings; some clever trick
}>. It will be alot of work to keep user-friendly warnings from
becoming expert-hostile.

I would suggest you consider this a seperate project to the default
warnings issue, both for scope and political reasons.

I'd also suggest you start to keep a catalog of difficult warnings and
how you think they should act for the time being.


However, how does this help against the large spew of warnings which
will come from unclean code turning on warnings for the first time?
No matter how touchy-feely they are, there's going to be a whole lot
of them.

As a perfect example, I invite you to try something like this:

cd ~/src/perl-current/t
./perl -w lib/bigfloat.t

This produces 1467 lines of warnings (3X more than the size of the
program), almost entirely "use of uninitialized value" warnings. Even
I'm afraid to dig in and fix it, forget about someone who's still wet
behind the ears and has a deadline to meet.

This is a perfect example of a warning which is too clever.

Its not necessarily wrong to have a function which accepts undef as a
value. In fact, its often very useful in cases where a routine is
expecting a false value.

A warning like this takes the decision of what values a routine takes
out of the hands of the function author. There is no easy way for the
function to say "no really, I was expecting an undef" because the
warning originates at the caller's code.

Any attempt to define a way for a function to declare that undef
values are ok, beyond the author ad-hoc coding it, lies down a
blasted, pock-marked road called "Function Prototypes". That's way
out of the scope of this conversation.

We've already had a rather large discussion about what to do with
undef on perl-qa. It starts here:
http://archive.develooper.com/perl-qa@perl.org/msg00180.html

As a language designer, you have to be very, very careful about what
you are going to consider to be coding mistakes and what falls under
artistic license. Perl has a strong tradition of being very liberal
with that license, and I think its one of its strong points. If
nothing else, it makes it fairly unique amongst modern programming
languages where the trend lately has been to restrict in the name of
legislating good style.


Coincidentally, Carp exists exactly for this purpose. Its point is to
make it appear the error occurs at the point a routine was called,
rather than inside the error itself:

use Carp
sub foo {
carp "Uninitialized value passed to function foo()"
unless defined $_[0]
}

foo(undef);

Uninitialized value passed to function foo() at -e line 1
main::foo(undef) called at -e line 1

What's the incentive? That warm fuzzy feeling of squashing a bug
doesn't apply, many people don't consider warnings to be bugs (even
though they should, but that's a much larger battle).

undef is just a sentinel value, its morality is elastic.

Its all part of trying to keep perl6-language from being a dumping
ground. CC it to perl6-language and perl6-meta, but please set the
reply-to here.

oops -- posted to perl6-language by mistake...

sorry,

Ed
----

Oops. Forgot a few points. I said that you should give me the courtesy of
responding to all of my points, and
No we are not. If you come up with some good counter arguments, maybe. I am the
first person to admit when someone else has a good point. In fact I *did* admit
it when you brought up the point about 'splitting the language in two'.

But in this case, I just have not seen it. It just looks like you are being
political, bowing to what others have said. Sorry, but that's the truth...
well, ok then, you've got two ways to go then. 1) make it so '-w' is useful
enough that beginners can use it successfully, or 2) rest your head on its
laurels, and not improve things.

I thought the point of perl6 was to fix lots of the problems of perl5. If perl6
is going to be a lukewarm perl5 wannabe, then I have no interest in working on
it, and ruby/python et al will eat it alive. And the only reason it will survive
will be because of inertia.
yeah, but that's the point, isn't it? Perl6 is supposed to be *better* than
perl5, right?
And why?
right, and your point is? Shouldn't Larry have all the options in front of him
when he makes his mind up?

Surprisingly, the only strong reaction I've heard from is *you*. I want to
further test those waters by making an RFC that suggests the opposite of RFC 16.
And see where it goes, whether I could fare better than you did. After all,
there's a lot more ammo here now than before.
See my other post. For me, 'warnings clean' means the ability to handle
undef input, integers and strings, and tell the error from the point of view
of the caller, not the callee.

Not only do I want to make warnings on by default, I want to make it *usable*
for warnings to be on by default.
?????

There are a lot of things that can mitigate this problem:

1) intelligent code-sensors that can see if your syntax is perl5 or perl6, and
parse accordingly. I personally would like to see a couple of huge
incompatibilities for simply that reason. Call print 'output' for example.

2) maybe for a couple of generations you'll have to put 'use perl6' up at top
of your program, not 'use perl5'

3) all modules in '5.6.0' will have an implicit 'use perl5' up top, and all
modules in '6' will have a 'use perl6'.

etc. etc. etc. And anyways this is pointless. If perl6 is a lukewarm perl5,
then why upgrade at all? I like 1) a lot simply because it means I don't need
to do a thing. But 2 and 3 are good ideas too.
Great. Then lets put it in stone, OK. In an RFC? Like I said, I haven't heard
these particular arguments before. That's why I'm making them.
Yes I do..

Anyways, I believe this is where I started in the other post... go to it for
replies to the rest of your arguments.

Ed

From: Edward Peschko

...
From perllexwarn:

-W

If the -W flag is used on the command line, it will enable
all warnings throughout the program regardless of whether warnings
were disabled locally using no warnings or $^W =0. This includes all
files that get included via use, require or do. Think of it as the
Perl equivalent of the ``lint'' command.

Paul

_________________________________________________________

hmm. No mention in the camel.

Ah well, i'll think of that when I write the RFC.

Ed

Then you're looking in the wrong Camel. It's on page 502 in the first
printing of the third edition.

It seems to me that *that* is your main problem. Not the fact that
strict and warnings aren't put in by the perl interpreter itself, but
that perl code is so difficult to debug. Something as simple as
requiring variable declarations or initializing variables ought not take
hours of debugging, assuming that for the rest, the source works
reasonably OK. So,

A) a code profiler that can verify use of variables and stick a limited
scope onto every variable, plus optionaly initializing variables to ''
or 0, that might be handy at times.

B) perl's error messages could be somewhat more helpful. If you have a
here doc with 30 lines of interpolated pure text, it's extremely
annoying that perl will only point you to this data block (actually to
the line containign the "<<"), and just say "use of uninitialized value"
without saying *which* variable it is talking about. But, this has been
brought of on the perl6 lists a few times already.

All this could help strictifying and warn-proofing otherwise properly
working modules, in say, oh, five minutes.

I'm moving this over to perl6-language-strict.

Again, this splits the language into two halves. A library language
and a scripting language. Extremely confusing and sets a very, very,
very dangerous precedent.

And consider the maintenance nightmare. I have a routine in a script
which I decide goes better in a library. Suddenly, I'm playing under
a different set of rules.

Its not worth it. Its not worth saving 10 characters. Take a typing
class.

The amount of typing doesn't matter. Its the fact that you're putting
it on the command line when you run the program that's the problem.
The way strict is used, its either on or off. There are very, very
few cases where you want sometimes to run a particular program with
strict and sometimes without.

Good, I love cross-overs. It's not as good as a The Tick/Eraserhead
cross-over, but it'll do.
Eh? It's no different from arguing for no strict/no warnings as the
default being shoved down people's throats.
It's not necessarily big vs small, there's also novice vs adept. More on
this in a minute.
Agreed, and he will; that's never stopped the rest of us
flam^H^H^H^Hdiscussing it.
I just can't see this as a justification for lax reporting being the
default. If you leave -w/strict out, dollars to donuts it'll lead down the
road to bizarre run-time errors or incorrect behavior. But you don't leave
it out, you already said so. Why should we not give newbies the same
advantage until such time as they decide to turn it off for a JAPH or whatever?

Which is where I disagree with Edward; -q is not the training wheel, the
lack of it is.
Of course they aren't going to solve most/many/who cares how many basic
problems. I'm not claiming that we should advertise the feature that way.

I am saying that I have come across far too many people who were admittedly
far too lazy and who never bothered to find out about -w and use strict and
so got themselves into far more trouble than was necessary. If they had to
develop with those on, by the time they found out how to turn them off they
might be more enlightened. Or they would give up, figure that Perl was too
hard for them (possibly true; or that they were too dumb to be programming
anyway), and go away instead of causing havoc on clpm.
But it *isn't* a matter of someone else deciding you should work strict,
since you can turn it off with two characters. That's the training wheel
aspect; either someone gets to the point of finding out how to disable it
(and whether or not they should be doing that, at least they'll *know* they
are disabling messages), or they're just not cut out for tasks like reading
manuals, programming, or tying shoelaces. And if they *never* find out how
to disable the messages, then at least they'll generate better code with
strictness turned on, and won't end up driving people insane in clpm
pasting "run your code under -w and you'll see why it failed" in replies.
Maybe. It might also improve the majority of code out there to the point
where Perl's reputation is improved. In this area, it could stand it, IMHO.
If 1/10 of the stuff mooted for P6 gets in there, it'll be sufficiently
different from P5 that this will be a minor change.

With the difference that this time they'll know they're doing it, rather
than not knowing they're not enabling reporting.
I don't see this; unless perl6 is turned to spit out "Run again with -q to
remove this message" after every error, I don't think there's likely to be
a large underground movement of newbies papering "Run all your Perl
programs with -q" notices on lampposts. Point being, by the time they've
expended the effort to find out about -q, they should have a bit more of a
clue as to why it's not the default. Plus perlrun can say next to -q, "IF
YOU RUN WITH THIS FLAG NO-ONE WILL GIVE YOU ANY HELP, LUSER."
Now now, there's tons of discipline that isn't supplied even with
strict. And discipline that is supplied without it. strict/-w do not
constitute Java madness or you wouldn't be using Perl.
True, but I'm not claiming that changing the default will accomplish this,
only that it will accomplish what I already described. Look, the docs
already say that the fact that -w is not the default is a bug. What should
we do, change the docs? Or leave it in there for P6 and build a new
language with an admitted bug in it from the beginning?
Yes, but not the point.

Redirected to -strict to save the sanity of thousands of people who don't care.
This is, what's the word I'm looking for... nuts. We split code into
modules for purposes of reuse, not because it's somehow more worthy of
error checking. I don't want to have to remember this invisible
action-at-a-vast-distance rule to figure out why code in different places
behaves differently wrt pragmas.

Ctl-k baby
just like pico
now i'll tell you, perl is unix based baby!