Front page | perl.perl5.porters |
Postings from March 2001
Re: unexpected result of stringification.
From:
abigail
Date:
March 19, 2001 11:14
Subject:
Re: unexpected result of stringification.
Message ID:
20010319191826.2194.qmail@foad.org
On Mon, Mar 19, 2001 at 10:18:43AM -0600, Chris Stith wrote:
> On Sun, 18 Mar 2001 nick@ing-simmons.net wrote:
>
> > <abigail@foad.org> writes:
> > >On Mon, Mar 12, 2001 at 11:59:24AM +0000, Nick Ing-Simmons wrote:
> > >> >
> > >> >Is this a bug or not?
> > >>
> > >> It cannot be - changing either is bound to break something.
> > >>
> > >> >Is there a way to fix this?
> > >>
> > >> Not without breaking scripts which rely on the behaviour.
> > >
> > >
> > >I've a bit of a problem with that reasoning. That would mean you can
> > >never, ever fix a bug, because there's bound to break something.
> >
> > It is a way of defining what can be a bug. If the behaviour is useful
> > and likely to be used it isn't a bug it is a feature.
> >
> > > > print 'foo'=~/(.*)/ && $1, 'bar'=~/(.*)/ && $1, "\n";
> > > > print 'foo'=~/(.*)/ && "$1", 'bar'=~/(.*)/ && "$1", "\n";
> >
> > In this case I assume that there is an existing body
> > of code that expects $1 to to be the last value matched, so that making a copy
> > as it is passed to print (or subs in general) would break that code at least.
> > And the second line shows that there is an easy way to get the copy if that
> > is what you want.
>
> If there is, then that code is wrong. Code should never depend
> upon the order of evaluation within a single statement. Even
> when order of execution within a statement is defined by the
> language, it is a bad habit to count on it.
The only order of evaluation that the give example depends on is
that && evaluate its left operand before its right operand, and
that function arguments are evalutated before the function is
called.
You claim that's a bad thing?
> Remember, Perl not only tries to be portable among machines, but
> also among the minds of programmers with different backgrounds.
> This principle is often mentioned by the community, but they usually
> call it the Principle of Least Surprise. While many things in Perl
> differ from whatever language a programmer may have experienced,
> code that breaks the very tenets of good style in other languages
> may confound a maintenance programmer - or, perhaps more importantly,
> may confound someone who is translating Perl source to another
> language (in particular, I'm thinking of C) in which order of execution
> within a statement is not necessarily defined. It could be worked
> around in translation, but that could be a pain.
None of this is relevant to the thing under discussion, is it? As for
the ease of hand translating Perl to C, I don't that's important when
you want to discuss how Perl should behave. You might as well argue that
Perl should not short circuit boolean operators but always evaluate both
operands - that would make it easier to translate Perl to Pascal. And
perhaps we need to get rid of closures, for the benefit of the few that
translate Perl to Python.
Abigail