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:[EMAIL PROTECTED]/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.
