develooper Front page | perl.perl5.porters | Postings from July 2010

Re: [perl #76438] peephole optimiser could prune more dead code

Thread Previous | Thread Next
Nicholas Clark
July 13, 2010 06:18
Re: [perl #76438] peephole optimiser could prune more dead code
Message ID:
On Tue, Jul 13, 2010 at 01:11:11PM +0000, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jul 13, 2010 at 11:43, Ben Morrow <> wrote:
> > Perl doesn't have undefined behaviour. No matter what weasel words
> > copied from stdc made it into the ++ docs, Perl's actual evaluation
> > order has always been straightforward and well-defined. Changing this
> > may be worth it, for a sufficiently beneficial optimisation, but it is
> > definitely a backwards-incompatible change.
> Undefined doesn't mean that the implementation doesn't act
> consistently, just that its documentation explicitly denies
> responsibility for having those things work in the future. If they
> work now they only work incidentally, and you shouldn't rely on them.

    Briefly: implementation-defined means that an implementation must choose
    some behavior and document it.  Unspecified means that an implementation
    should choose some behavior, but need not document it.  Undefined means
    that absolutely anything might happen.

I suspect that all of our documentation should say "unspecified" rather than

> Of course we can't liberally change things that are documented to be
> undefined as liberally as a C compiler would, becuase there's only one
> perl(1) but multiple cc(1)'s.

But whatever we call it, that's the key problem. There is only one
implementation, and as that implementation strives hard to internally avoid
C undefined behaviour, its output will be deterministic, in some fashion.
Hence people come to rely on the current behaviour of the implementation,
documented or not.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About