FAQ

Re: Warnings, strict, and CPAN

Schwern
Feb 16, 2001 at 10:33 pm
This is a cross-over from perl6-language.


First off, I'd like to make it clear that I'm *not* arguing against
the advantages of having strict and warnings on. I turn them on for
every program I write (except strict for one-liners) and strongly
advocate that everyone else do the same. However, I'm not about to
shove my style down other's throats.

On Thu, Feb 15, 2001 at 09:09:59PM -0800, Edward Peschko wrote:
yeah, there are programmers and there are people who contribute to CPAN.
I'd say they were a separate subset.
Any schmoe can post code to CPAN, there's nothing magical about it and
it doesn't suddenly make one a better class of programmer. But I
think you were implying a higher class of quality controls for CPAN
code due to their potential wide-spread impact. This is true, but its
a whole 'nother ball of wax.

strict by default is right out. That's not the sort of language Perl is.
that's no argument. That's a solipsism.
I think its a tautology. ;)

Anyhow, there's two camps on this issue, those who use Perl for big
things and those who use Perl for small things. They have different
requirements and will (and have) argue until they're blue in the face
about them.

I say, if you're writing 10 lines, adding another (no strict or -q) is
annoying. If you're writing 1000 lines, adding another is no big
thing.

Let Larry figure out how to slice this knot.

I'm the bloody QA chair and I don't even think its a good idea anymore.
what difference does that make?
In and of itself, none. But I do deal with this sort of thing all the
time. How do you make software more readable, more maintainable,
higher quality, less bugs, easier to write? I read books and papers
on the subject. I (try) to teach people and watch them struggle with
the process. I have to read, document and refactor reams of other
people's code. I practice it all myself (and screw up alot).

What I have found is shoving extra strictness and verbosity down a
newbie's throat generally doesn't work. Often, they just either learn
to ignore it, shut it off or otherwise work around it. It all depends
on the person, but humans, as a rule, don't like things which increase
short-term work (even if it'll decrease their long-term) until they've
already made their own mistakes and wasted that long-term time.

Also, programmers hate computers telling them they're wrong (users
seem to expect it) without having asked them. Its a big, nasty
sociological and psychologial problem.

Basically, I want '-w' back as a useful tool.
That's interesting, why isn't it useful now? And why is that related
to making it the default? (I'm honestly curious)

Exactly. That's the point - everything breaks. I don't want people to be
forced to 'use strict' and 'use warnings'. All I want is their files to have
a POLICY towards 'use strict' and 'use warnings'.
I'm not sure what you mean by a policy. Do you mean you want people
to have to say C<no strict; no warnings;> explicitly? Do you want to
make it a conscious decision to shut off the safeguards?

You have to do all this anyway, flipping a few command line switches
isn't going to solve fundemental software engineering problems. Yes,
it would be nice if warnings were on by default, but it has too many
caveats. Its also all to easy to be shut off (and don't think that's
not the first switch a newbie will find).
Of course, I wouldn't mind if the newbie found the switch. Ultimately, I bet
lots of the newbies outgrow the switch though. And note that the switch
is there and *WELL ADVERTISED*. Not hidden in the docs.
I don't understand what you mean, and I think I didn't make myself
clear either.

Using -w and -Mstrict *isn't* going to solve most basic software
engineering problems. Neither is -q. No single command or function
or switch will. You've got to have the whole process in place, you've
got to make a conscious decision to do it.

Do I have to invoke NSB? ;)

Supply your own discipline, don't make the language do it or you will
be sorry. (Devo moment... "Freedom of choice is what you got, freedom
But that's the point. You *are* supplying your own discipline. You
are proactively stating by using '-q' that you want do have *lax*
discipline, more lax than the perl interpreter has to offer by
default.
Now I'm completely lost. Making perl quiet is a *bad* thing in the
long run. Its a symptom of a lack of programming discipline. That
you're giving up on trying to make your program run properly.

When I say supply your own discipline, that doesn't mean you shut off
warnings and audit your own code for mistakes and errors. It means
you consciously decide to work in a strict environment. However, it
doesn't mean somebody *else* decides you should work in a strict
environment. We have enough languages which do that TYVM.

So - how about it? As I see it, the new points are:

1) the fact that forgetting 'use strict' is painful and forgetting
the proposed '-q' or '-z' is painless.
I like strict, you like strict, lots of other people really, really
don't like it. Large-scale Perl programmers want strict on,
small-scale like to have it off. I'm not going to repeat the reasons
here, dig through the perl6-language-strict archives for them. Both
have valid arguments, both represent large chunks of the community.

We have a case where the two sides win conditions are conflicting.
Keeping strict off has one major advantage, it won't break any
existing code. Turning it on by default will break probably the
majority of code out there. That would be Bad. We don't want
everyone to have to run their entire code-base through p526. The net
result will be people running 5.6 in 2010.

That's what is boils down to.

2) the fact that I'm NOT trying to hide '-q' from users, but advertising
its existence upto the point where it comes along with every single
perl command that has errors for the beginning two iterations of
perl.
Yes, people will find it and they will use it. Thus defeating the
point of having warnings and strict default.

If you try to enforce discipline without understanding they will
simply work around it.

3) the point that I am not aiming for a software standards but
for the modules on CPAN to have a strictness and warnings *policy*.
Assuming a policy is C<no warnings; no strict>, what's the net gain
here? What does having this in hand really do for us?

4) that '-w' is fundamentally broken as it stands and has to be fixed.
Hello, what? I missed this, could you point me to the discussion?

In addition, I think that the whole idea of 'upgrade NOTES' is
something worth exploring.
Is this different than a perl6delta man page? I must have missed
this, too.

And don't dismiss 1 as trivial. I personally have spent hours
tracking down simple bugs that I otherwise would have found within
SECONDS with 'use strict'.
So turn on strict!! First thing, before you start debugging. Perl
does not supply the discipline, that way Java^WMadness lies.

Instead of Yet Again arguing back and forth on this, go write me some
code auditing tools.
hey, but this fight is worth fighting.
No, its really not. You're just charging back and forth over the same
old No Man's Land. No matter what the decision, one side or the other
will be cheesed off and no real net gain will be had.

Good programmers will still be good programmers and bad programmers
will still be bad, no matter how many switches you flip or pragmas you
make them use.

No language will solve this. No Silver Bullet.
reply

Search Discussions

37 responses

  • Edward Peschko at Feb 16, 2001 at 11:28 pm

    Basically, I want '-w' back as a useful tool.
    That's interesting, why isn't it useful now? And why is that related
    to making it the default? (I'm honestly curious)
    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.
    I'm not sure what you mean by a policy. Do you mean you want people
    to have to say C<no strict; no warnings;> explicitly? Do you want to
    make it a conscious decision to shut off the safeguards?
    Yes!
    Of course, I wouldn't mind if the newbie found the switch. Ultimately, I bet
    lots of the newbies outgrow the switch though. And note that the switch
    is there and *WELL ADVERTISED*. Not hidden in the docs.
    I don't understand what you mean, and I think I didn't make myself
    clear either.
    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.
    Using -w and -Mstrict *isn't* going to solve most basic software
    engineering problems. Neither is -q. No single command or function
    or switch will. You've got to have the whole process in place, you've
    got to make a conscious decision to do it.

    Do I have to invoke NSB? ;)
    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...
    But that's the point. You *are* supplying your own discipline. You
    are proactively stating by using '-q' that you want do have *lax*
    discipline, more lax than the perl interpreter has to offer by
    default.
    Now I'm completely lost. Making perl quiet is a *bad* thing in the
    long run. Its a symptom of a lack of programming discipline. That
    you're giving up on trying to make your program run properly.
    Think of it this way - you'd sell '-q' as 'training wheels' for your
    bike. Something to soften the learning curve.
    When I say supply your own discipline, that doesn't mean you shut off
    warnings and audit your own code for mistakes and errors. It means
    you consciously decide to work in a strict environment. However, it
    You are consciously deciding to work in a strict environment. You are
    consciously deciding not to use the '-q' switch.
    doesn't mean somebody *else* decides you should work in a strict
    environment. We have enough languages which do that TYVM.
    Well, not many languages provide you with training wheels...
    So - how about it? As I see it, the new points are:

    1) the fact that forgetting 'use strict' is painful and forgetting
    the proposed '-q' or '-z' is painless.
    I like strict, you like strict, lots of other people really, really
    don't like it. Large-scale Perl programmers want strict on,
    small-scale like to have it off. I'm not going to repeat the reasons
    here, dig through the perl6-language-strict archives for them. Both
    have valid arguments, both represent large chunks of the community.
    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.
    We have a case where the two sides win conditions are conflicting.
    Keeping strict off has one major advantage, it won't break any
    existing code. Turning it on by default will break probably the
    majority of code out there. That would be Bad. We don't want
    everyone to have to run their entire code-base through p526. The net
    result will be people running 5.6 in 2010.
    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.
    That's what is boils down to.

    2) the fact that I'm NOT trying to hide '-q' from users, but advertising
    its existence upto the point where it comes along with every single
    perl command that has errors for the beginning two iterations of
    perl.
    Yes, people will find it and they will use it. Thus defeating the
    point of having warnings and strict 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
    If you try to enforce discipline without understanding they will
    simply work around it.

    3) the point that I am not aiming for a software standards but
    for the modules on CPAN to have a strictness and warnings *policy*.
    Assuming a policy is C<no warnings; no strict>, what's the net gain
    here? What does having this in hand really do for us?
    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.
    4) that '-w' is fundamentally broken as it stands and has to be fixed.
    Hello, what? I missed this, could you point me to the discussion?
    Again, see up top. '-w' is a global flag, and hence you get thousands
    of global warnings.
    In addition, I think that the whole idea of 'upgrade NOTES' is
    something worth exploring.
    Is this different than a perl6delta man page? I must have missed
    this, too.
    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))!
    And don't dismiss 1 as trivial. I personally have spent hours
    tracking down simple bugs that I otherwise would have found within
    SECONDS with 'use strict'.
    So turn on strict!! First thing, before you start debugging. Perl
    does not supply the discipline, that way Java^WMadness lies.
    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.
    No, its really not. You're just charging back and forth over the same
    old No Man's Land. No matter what the decision, one side or the other
    will be cheesed off and no real net gain will be had.
    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.
    Good programmers will still be good programmers and bad programmers
    will still be bad, no matter how many switches you flip or pragmas you
    make them use.

    No language will solve this. No Silver Bullet.
    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
  • Schwern at Feb 17, 2001 at 1:41 am

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

    I'm not sure what you mean by a policy. Do you mean you want people
    to have to say C<no strict; no warnings;> explicitly? Do you want to
    make it a conscious decision to shut off the safeguards?
    Yes!
    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'.

    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.
    No, people will just shut it off pretty quick. This gains nothing.

    Now I'm completely lost. Making perl quiet is a *bad* thing in the
    long run. Its a symptom of a lack of programming discipline. That
    you're giving up on trying to make your program run properly.
    Think of it this way - you'd sell '-q' as 'training wheels' for your
    bike. Something to soften the learning curve.
    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?

    We have a case where the two sides win conditions are conflicting.
    Keeping strict off has one major advantage, it won't break any
    existing code. Turning it on by default will break probably the
    majority of code out there. That would be Bad. We don't want
    everyone to have to run their entire code-base through p526. The net
    result will be people running 5.6 in 2010.
    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.
    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!

    Yes, people will find it and they will use it. Thus defeating the
    point of having warnings and strict 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
    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.

    Assuming a policy is C<no warnings; no strict>, what's the net gain
    here? What does having this in hand really do for us?
    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.
    There is no win here. People will shut it off without thinking.

    Again, see up top. '-w' is a global flag, and hence you get thousands
    of global warnings.
    I think this is covered by "use warnings".

    Is this different than a perl6delta man page? I must have missed
    this, too.
    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. <snip>
    WARNING: scalar assignment to a list. NOTE - this has changed since perl5
    $a = $b, $d now parses as ($a = ($b, $d))!
    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.

    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.
    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.
  • Peter Scott at Feb 17, 2001 at 2:06 am

    At 08:41 PM 2/16/01 -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 03:28:36PM -0800, Edward Peschko wrote:
    In the same way that I unconsciously type '-wle' in all my one-liners,
    people will write '-q'.
    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.
    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 absolutely disagree with outputting that message. It defeats the purpose
    and trains people to use -q without thinking why.
    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... Exactly.
    Come to think of it, what language or popular compiler does have
    run-time (not compile-time) warnings on by default?
    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.
    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!
    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.
    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.
    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.
    Assuming a policy is C<no warnings; no strict>, what's the net gain
    here? What does having this in hand really do for us?
    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.
    There is no win here. People will shut it off without thinking.
    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...
    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.
    I think I tried that a couple of times :-)
    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.
    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.

    --
    Peter Scott
    Pacific Systems Design Technologies
  • Schwern at Feb 17, 2001 at 2:36 am

    On Fri, Feb 16, 2001 at 06:08:20PM -0800, Peter Scott wrote:
    Come to think of it, what language or popular compiler does have
    run-time (not compile-time) warnings on by default?
    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.
    Not quite the point. I'm looking for an analogous situation so we can
    use the result as something of a case-study.

    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.
    Perl 6 is going to break things, fine. But break them for a better
    reason than saving a few keystrokes, please.

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

    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.
    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...
  • Peter Scott at Feb 17, 2001 at 3:06 am

    At 09:36 PM 2/16/01 -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 06:08:20PM -0800, Peter Scott wrote:
    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.
    Perl 6 is going to break things, fine. But break them for a better
    reason than saving a few keystrokes, please.
    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.
    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.
    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.
    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.
    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".
    Okay, but these people are not going to be put out by sticking -q on the #!
    line.
    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.
    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).
    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.
    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 like the lack of it has already pissed off 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.
    I don't find the ideas vague... and they could save clpm from descending
    into a cesspool of iniquity. Oops, too late...
    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...
    All agreed, and orthogonal. So you concede the point, eh? :-)
    --
    Peter Scott
    Pacific Systems Design Technologies
  • Schwern at Feb 17, 2001 at 4:00 am

    On Fri, Feb 16, 2001 at 06:52:22PM -0800, Peter Scott wrote:
    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.
    You're making it sound like -w is a personal tutor!

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

    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".
    Okay, but these people are not going to be put out by sticking -q on the #!
    line.
    We're talking about the folks who call things 'ls' instead of 'dir'
    because its one less character to type, right?

    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.
    Perhaps, but its common.

    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 like the lack of it has already pissed off lots of people :-)
    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.
  • Peter Scott at Feb 17, 2001 at 6:44 am

    At 11:00 PM 2/16/01 -0500, schwern@pobox.com wrote:
    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.
    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.
    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.
    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".
    Okay, but these people are not going to be put out by sticking -q on the #!
    line.
    We're talking about the folks who call things 'ls' instead of 'dir'
    because its one less character to type, right?
    Oh well, then we should call the new executable 'p' instead of 'perl'.

    I checked... it's not taken...
    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 like the lack of it has already pissed off lots of people :-)
    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.
    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...

    --
    Peter Scott
    Pacific Systems Design Technologies
  • Schwern at Feb 17, 2001 at 7:48 am

    On Fri, Feb 16, 2001 at 10:45:27PM -0800, Peter Scott wrote:
    Help me out here. You're saying:
    <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.

    Oh well, then we should call the new executable 'p' instead of 'perl'.
    Don't laugh, I've seen people do even more rediculous shell aliasing
    for similar results.

    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 like the lack of it has already pissed off lots of people :-)
    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.
    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.
    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.
  • Peter Scott at Feb 17, 2001 at 7:23 pm

    At 02:47 AM 2/17/01 -0500, schwern@pobox.com wrote:
    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.
    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.
    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.
    --
    Peter Scott
    Pacific Systems Design Technologies
  • Peter Scott at Feb 17, 2001 at 6:49 am

    At 11:00 PM 2/16/01 -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 06:52:22PM -0800, Peter Scott wrote:
    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.
    You're making it sound like -w is a personal tutor!
    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?
    nodammit
    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.

    --
    Peter Scott
    Pacific Systems Design Technologies
  • Edward Peschko at Feb 17, 2001 at 2:22 am

    On Fri, Feb 16, 2001 at 08:41:02PM -0500, schwern@pobox.com 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'.
    I'm not sure what you mean by a policy. Do you mean you want people
    to have to say C<no strict; no warnings;> explicitly? Do you want to
    make it a conscious decision to shut off the safeguards?
    Yes!
    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.
    and your point?
    In the same way that I unconsciously type '-wle' in all my one-liners,
    people will write '-q'.
    Fine - let them do that.

    People will get the point pretty quick.
    No, people will just shut it off pretty quick. This gains nothing.
    Yes it does. It tells them about '-q' in a way that they don't have to
    be searching through it in the manual.
    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...
    Fine, let them think its annoying. They might think this for a while, and
    then think *why* the '-q' is there, etc. etc. etc.
    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.
    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!
    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.
    Ok, saving ten characters of typing per file is not a valid reason to
    do anything, so nix that.
    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.
    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.
    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.
    There is no win here. People will shut it off without thinking.
    I don't think so... Anyways,
    Again, see up top. '-w' is a global flag, and hence you get thousands
    of global warnings.
    I think this is covered by "use warnings".
    No it isn't - '-w' is a global flag for a *reason*. If everybody had a
    warnings policy, it would become useful again.
    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. <snip>
    WARNING: scalar assignment to a list. NOTE - this has changed since perl5
    $a = $b, $d now parses as ($a = ($b, $d))!
    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.
    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 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.

    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.
    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...)
  • Schwern at Feb 17, 2001 at 3:13 am

    On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote:
    On Fri, Feb 16, 2001 at 08:41:02PM -0500, schwern@pobox.com 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.

    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.

    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.
    and your point?
    In the same way that I unconsciously type '-wle' in all my one-liners,
    people will write '-q'.
    Fine - let them do that.
    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?!"

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

    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'

    Ta da.

    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.
    no it isn't.
    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

    Again, see up top. '-w' is a global flag, and hence you get thousands
    of global warnings.
    I think this is covered by "use warnings".
    No it isn't - '-w' is a global flag for a *reason*. If everybody had a
    warnings policy, it would become useful again.
    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).

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

    (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...)
    Came up when I tried this earlier. I drew the line between -e and not -e.
  • Peter Scott at Feb 17, 2001 at 3:43 am

    At 10:13 PM 2/16/01 -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote:
    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'.
    I do not agree with this argument of Edward's.
    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>).
    But wouldn't -W still do what it does now?
    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!
    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.



    --
    Peter Scott
    Pacific Systems Design Technologies
  • Edward Peschko at Feb 17, 2001 at 5:04 am

    On Fri, Feb 16, 2001 at 10:13:07PM -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 06:22:45PM -0800, Edward Peschko wrote:
    On Fri, Feb 16, 2001 at 08:41:02PM -0500, schwern@pobox.com 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
  • Schwern at Feb 17, 2001 at 7:37 am
    I think we're rapidly approaching "agree to disagree" territory here.

    On Fri, Feb 16, 2001 at 09:03:54PM -0800, Edward Peschko wrote:
    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.
    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.

    forgetting to type 'use strict' in your script and 'use warnings' is
    a syntax error to me.
    YMMV wildly. Again, I do not disagree with your opinion and hold
    nearly the same myself, but you'll find fairly strong reactions
    otherwise.

    4. to make '-w' usable again
    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.

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

    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.
    Larry reads the mailing lists, too. He's unfortunately already
    probably read these same arguements a few times already.

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

    So the only thing that '-Mstrict' *can* do is force you to have strict at
    the beginning of your script.
    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??

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

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

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

    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.
    ??? which new scheme?

    As for the string 'use warnings' in OR outside the perl distribution, well
    there are *no* uses. At all.
    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.
  • Peter Scott at Feb 17, 2001 at 7:07 pm

    At 02:37 AM 2/17/01 -0500, schwern@pobox.com wrote:
    On Fri, Feb 16, 2001 at 09:03:54PM -0800, Edward Peschko wrote:
    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.
    No, there will probably be a big push to shut it off, based on
    historical reactions to this sort of thing.
    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?
    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.
    Hmm, its damned silly that you can't give two modules on the command
    line.
    ???

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

    --
    Peter Scott
    Pacific Systems Design Technologies
  • Schwern at Feb 17, 2001 at 7:49 pm

    On Sat, Feb 17, 2001 at 11:09:29AM -0800, Peter Scott wrote:
    No, there will probably be a big push to shut it off, based on
    historical reactions to this sort of thing.
    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?
    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!

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

    $ perl -Mwarnings -Mstrict -le 'print keys %INC'
    Exporter.pmCarp.pmstrict.pmwarnings.pm
    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.
  • Peter Scott at Feb 18, 2001 at 12:59 am

    At 02:49 PM 2/17/01 -0500, schwern@pobox.com wrote:
    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.

    --
    Peter Scott
    Pacific Systems Design Technologies
  • Simon Cozens at Feb 18, 2001 at 4:45 am

    On Sat, Feb 17, 2001 at 05:00:51PM -0800, Peter Scott wrote:
    Simon Cozens submitted a patch which failed the test
    ...and MJD and Jarkko and I worked on it and we put together something
    which was OK.

    --
    You're not Dave. Who are you?
  • Schwern at Feb 18, 2001 at 6:11 am

    On Sun, Feb 18, 2001 at 04:45:46AM +0000, Simon Cozens wrote:
    On Sat, Feb 17, 2001 at 05:00:51PM -0800, Peter Scott wrote:
    Simon Cozens submitted a patch which failed the test
    ...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);
    }
    }
    }
  • Jarkko Hietaniemi at Feb 18, 2001 at 5:13 pm

    On Sun, Feb 18, 2001 at 01:11:35AM -0500, schwern@pobox.com wrote:
    On Sun, Feb 18, 2001 at 04:45:46AM +0000, Simon Cozens wrote:
    On Sat, Feb 17, 2001 at 05:00:51PM -0800, Peter Scott wrote:
    Simon Cozens submitted a patch which failed the test
    ...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
    Applied, thanks.

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Jarkko Hietaniemi at Feb 18, 2001 at 5:18 pm

    --- t/run/runenv.t 2001/02/18 05:58:06 1.1
    +++ t/run/runenv.t 2001/02/18 06:09:10
    Applied, thanks.
    (Had to add run/*.t to the list of testables in t/TEST.)

    --
    $jhi++; # http://www.iki.fi/jhi/
    # There is this special biologist word we use for 'stable'.
    # It is 'dead'. -- Jack Cohen
  • Peter Scott at Feb 18, 2001 at 1:27 am

    At 02:49 PM 2/17/01 -0500, schwern@pobox.com wrote:
    On Sat, Feb 17, 2001 at 11:09:29AM -0800, Peter Scott wrote:
    No, there will probably be a big push to shut it off, based on
    historical reactions to this sort of thing.
    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?
    Try it and see! I'm serious. It'll be an interesting experiment.
    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.


    --
    Peter Scott
    Pacific Systems Design Technologies
  • Schwern at Feb 18, 2001 at 1:38 am

    On Sat, Feb 17, 2001 at 05:28:51PM -0800, Peter Scott wrote:
    Why this difference depending on whether I reference a module with an
    absolute path or a relative one?
    That's very, umm... interesting. Hmm. Post it to p5p, see what happens.
  • Edward Peschko at Feb 17, 2001 at 9:31 pm

    I thought that was the problem you were having. Forgetting to type
    "use strict" in your programs.
    No -- its *anywhere* that you write scripts/modules/what have you. Anywhere
    you miss it, it is a syntax error to me.
    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??
    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.
    For your own development, sure. But that's your problem. Me? I have
    a laptop that I use everywhere. :P
    And for almost everybody else's.
    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
    that is a straw dog. It is not what I said.
    optimization since the process of making a non-strict program strict
    is extremely non-trivial.
    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.
    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.
    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.
    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.
    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.
    You don't. Since '-w' is no longer needed in its present meaning, you can turn
    on '-w' to get its new meaning.
    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.
    ??? which new scheme?
    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.
    As for the string 'use warnings' in OR outside the perl distribution, well
    there are *no* uses. At all.
    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).
    12%. Wow. that shows how beneficial people think warnings are..
    Checking my site_perl, I come up with 62 modules (again, about 12%)
    that play with $^W.
    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.
    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.
    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
  • Schwern at Feb 17, 2001 at 11:13 pm

    On Sat, Feb 17, 2001 at 01:31:27PM -0800, Edward Peschko wrote:
    I thought that was the problem you were having. Forgetting to type
    "use strict" in your programs.
    No -- its *anywhere* that you write scripts/modules/what have you. Anywhere
    you miss it, it is a syntax error to me.
    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.

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

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

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

    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.
  • Edward Peschko at Feb 18, 2001 at 10:16 pm

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

    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.
    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.
    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.
    Why haven't you fixed this? Why haven't you even reported this?! Why
    isn't this a test case??
    Again, I don't think it is carp's fault. I think its the programmers fault.
    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).
    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.
    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';
    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.
    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.
    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. :-(
    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.
    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
  • Schwern at Feb 18, 2001 at 11:11 pm

    On Sun, Feb 18, 2001 at 02:16:21PM -0800, Edward Peschko wrote:
    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..
    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.

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

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

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

    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';
    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.
    undef is just a sentinel value, its morality is elastic.

    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.
    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.
  • Edward Peschko at Feb 17, 2001 at 10:04 pm
    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
    I think we're rapidly approaching "agree to disagree" territory here.
    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...
    On Fri, Feb 16, 2001 at 09:03:54PM -0800, Edward Peschko wrote:
    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.
    No, there will probably be a big push to shut it off, based on
    historical reactions to this sort of thing.
    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.
    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.
    yeah, but that's the point, isn't it? Perl6 is supposed to be *better* than
    perl5, right?
    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.
    And why?
    forgetting to type 'use strict' in your script and 'use warnings' is
    a syntax error to me.
    YMMV wildly. Again, I do not disagree with your opinion and hold
    nearly the same myself, but you'll find fairly strong reactions
    otherwise.
    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.
    4. to make '-w' usable again
    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.
    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.
    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.
    ?????

    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.
    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.
    Larry reads the mailing lists, too. He's unfortunately already
    probably read these same arguements a few times already.
    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.
    Anyhow, you don't want it to work in universal scope. I think we're
    in agreement there.
    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
  • Paul Marquess at Feb 18, 2001 at 7:32 pm
    From: Edward Peschko

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

    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com address at http://mail.yahoo.com
  • Edward Peschko at Feb 18, 2001 at 10:18 pm

    On Sun, Feb 18, 2001 at 07:30:50PM -0000, Paul Marquess wrote:
    From: Edward Peschko

    ...
    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.
    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.
    hmm. No mention in the camel.

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

    Ed
  • Peter Scott at Feb 19, 2001 at 2:03 am

    At 02:18 PM 2/18/01 -0800, Edward Peschko wrote:
    On Sun, Feb 18, 2001 at 07:30:50PM -0000, Paul Marquess wrote:
    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.
    hmm. No mention in the camel.
    Then you're looking in the wrong Camel. It's on page 502 in the first
    printing of the third edition.
    --
    Peter Scott
    Pacific Systems Design Technologies
  • Bart Lateur at Feb 19, 2001 at 12:16 am

    On Fri, 16 Feb 2001 21:03:54 -0800, Edward Peschko wrote:
    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.
    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.

    --
    Bart.
  • Schwern at Feb 17, 2001 at 1:10 am
    I'm moving this over to perl6-language-strict.

    On Fri, Feb 16, 2001 at 03:48:22PM -0800, Edward Peschko wrote:
    Why? Its not the filename, its how its used -

    require("A"); # library - strict, warnings on
    use A; # library - strict, warnings on
    do "A" # library - strict, warnings on but who cares, do is
    # hardly ever used.

    eval("\$a = '1'"); # code - strict off
    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.

    It doesn't make much sense to make 'strict' an easy command line flag.
    strict is something you want on either all the time or not at all
    (with regards to a single program).
    Well, its the converse of '-q'. If people are too damn lazy to type
    '-q' and get what they want, well hell, I'll just have to type
    '-W'. And its less typing than '-w -Mstrict' or 'use strict; use
    warnings;'
    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.
  • Peter Scott at Feb 17, 2001 at 1:33 am

    At 05:33 PM 2/16/01 -0500, schwern@pobox.com wrote:
    This is a cross-over from perl6-language.
    Good, I love cross-overs. It's not as good as a The Tick/Eraserhead
    cross-over, but it'll do.
    First off, I'd like to make it clear that I'm *not* arguing against
    the advantages of having strict and warnings on. I turn them on for
    every program I write (except strict for one-liners) and strongly
    advocate that everyone else do the same. However, I'm not about to
    shove my style down other's throats.
    Eh? It's no different from arguing for no strict/no warnings as the
    default being shoved down people's throats.
    Anyhow, there's two camps on this issue, those who use Perl for big
    things and those who use Perl for small things. They have different
    requirements and will (and have) argue until they're blue in the face
    about them.
    It's not necessarily big vs small, there's also novice vs adept. More on
    this in a minute.
    I say, if you're writing 10 lines, adding another (no strict or -q) is
    annoying. If you're writing 1000 lines, adding another is no big
    thing.

    Let Larry figure out how to slice this knot.
    Agreed, and he will; that's never stopped the rest of us
    flam^H^H^H^Hdiscussing it.
    What I have found is shoving extra strictness and verbosity down a
    newbie's throat generally doesn't work. Often, they just either learn
    to ignore it, shut it off or otherwise work around it. It all depends
    on the person, but humans, as a rule, don't like things which increase
    short-term work (even if it'll decrease their long-term) until they've
    already made their own mistakes and wasted that long-term time.

    Also, programmers hate computers telling them they're wrong (users
    seem to expect it) without having asked them. Its a big, nasty
    sociological and psychologial problem.
    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.
    I'm not sure what you mean by a policy. Do you mean you want people
    to have to say C<no strict; no warnings;> explicitly? Do you want to
    make it a conscious decision to shut off the safeguards?
    Yes, although they could say -q instead of all that, or -e will still imply -q.
    Using -w and -Mstrict *isn't* going to solve most basic software
    engineering problems. Neither is -q. No single command or function
    or switch will. You've got to have the whole process in place, you've
    got to make a conscious decision to do it.
    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 that's the point. You *are* supplying your own discipline. You
    are proactively stating by using '-q' that you want do have *lax*
    discipline, more lax than the perl interpreter has to offer by
    default.
    Now I'm completely lost. Making perl quiet is a *bad* thing in the
    long run. Its a symptom of a lack of programming discipline. That
    you're giving up on trying to make your program run properly.

    When I say supply your own discipline, that doesn't mean you shut off
    warnings and audit your own code for mistakes and errors. It means
    you consciously decide to work in a strict environment. However, it
    doesn't mean somebody *else* decides you should work in a strict
    environment. We have enough languages which do that TYVM.
    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.
    I like strict, you like strict, lots of other people really, really
    don't like it. Large-scale Perl programmers want strict on,
    small-scale like to have it off. I'm not going to repeat the reasons
    here, dig through the perl6-language-strict archives for them. Both
    have valid arguments, both represent large chunks of the community.

    We have a case where the two sides win conditions are conflicting.
    Keeping strict off has one major advantage, it won't break any
    existing code. Turning it on by default will break probably the
    majority of code out there. That would be Bad.
    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.
    We don't want
    everyone to have to run their entire code-base through p526. The net
    result will be people running 5.6 in 2010.

    That's what is boils down to.
    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.

    2) the fact that I'm NOT trying to hide '-q' from users, but
    advertising
    its existence upto the point where it comes along with every single
    perl command that has errors for the beginning two iterations of
    perl.
    Yes, people will find it and they will use it. Thus defeating the
    point of having warnings and strict default.
    With the difference that this time they'll know they're doing it, rather
    than not knowing they're not enabling reporting.
    If you try to enforce discipline without understanding they will
    simply work around it.
    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."
    And don't dismiss 1 as trivial. I personally have spent hours
    tracking down simple bugs that I otherwise would have found within
    SECONDS with 'use strict'.
    So turn on strict!! First thing, before you start debugging. Perl
    does not supply the discipline, that way Java^WMadness lies.
    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.
    Instead of Yet Again arguing back and forth on this, go write me some
    code auditing tools.
    hey, but this fight is worth fighting.
    No, its really not. You're just charging back and forth over the same
    old No Man's Land. No matter what the decision, one side or the other
    will be cheesed off and no real net gain will be had.

    Good programmers will still be good programmers and bad programmers
    will still be bad, no matter how many switches you flip or pragmas you
    make them use.
    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?
    No language will solve this. No Silver Bullet.
    Yes, but not the point.
    --
    Peter Scott
    Pacific Systems Design Technologies
  • Peter Scott at Feb 17, 2001 at 1:50 am
    Redirected to -strict to save the sanity of thousands of people who don't care.
    At 03:48 PM 2/16/01 -0800, Edward Peschko wrote:
    Its a fine rationale, but I'm very, very loathe to implicitly split
    Perl into two seperate languages based on what the filename is.
    Why? Its not the filename, its how its used -

    require("A"); # library - strict, warnings on
    use A; # library - strict, warnings on
    do "A" # library - strict, warnings on but who cares, do is
    # hardly ever used.

    eval("\$a = '1'"); # code - strict off

    The functionality for adding 'strict' and 'warnings' would be added onto use
    and require.
    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.

    --
    Peter Scott
    Pacific Systems Design Technologies
  • PerlDiscuss - Perl Newsgroups and at Jul 6, 2004 at 5:31 am
    I think its a tautology. ;)
    Ctl-k baby
    just like pico
    Now I'm completely lost. Making perl quiet is a *bad* thing in the
    long run. Its a symptom of a lack of programming discipline. That
    you're giving up on trying to make your program run properly.
    now i'll tell you, perl is unix based baby!

Related Discussions