BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

I'm a big fan of 'constant functions' and pragmas (constant & enum) that create them for reasons, the knowledge of which seems to have become lost to the current generation of perlers; and is completely lost on the authors and proponents of the newer modules, like Readonly, that are billed as (very poor) substitutes for them.

I was working on my answer to syphilis' question in Re^3: unintentional conversion of signaling NaN to quiet NaN and thought to make a SNaN constant; and did, but I was testing it when I discovered something that is either very clever design; or simply a really cool bit of luck. I'm not sure which?

I implemented the constant very simply as:

use constant SNaN => unpack 'd',pack 'Q', 0x7ff0000000000001;

But how could I be sure that it was being properly reduced to a constant value?

With an integer constant it is quite simple with B::Deparse:

C:\test>perl -MO=Deparse -le"use enum qw[false true]; print 'fred' if +false; print 'bill' if true" use enum ('false', 'true'); '???'; print 'bill'; -e syntax OK

Sure enough, true & false have been defined as constant subs producing 1 & 0 respectively, and Perl has used their constant nature to optimise the code so that the entire print 'fred' if false; part of the program has been optimised away as it can never be executed. Likewise, the ... if true; has been optimised away since it can never be false. (Try that with Readonly :)

This also works with expressions that yield a constant value:

C:\test>perl -MO=Deparse -le"sub PI(){ 2*atan2(1,0) }; print PI; if( P +I == PI ) { print 'Here'; }" BEGIN { $/ = "\n"; $\ = "\n"; } sub PI () { 3.1415926535897931 } print 3.1415926535897931; do { print 'Here' }; -e syntax OK

The expression has been evaluated to a constant, a constant function created. And notably, the optimiser recognises that constant == constant is always(*) true, and the if condition has been optimised away.

But this one really impressed me;

C:\test>perl -MO=Deparse -le"use constant SNaN => unpack'd', pack'Q',0 +x7ff0000000000001; print SNaN; if( SNaN != SNaN ) { print 'here'; }" BEGIN { $/ = "\n"; $\ = "\n"; } use constant ('SNaN', unpack('d', pack('Q', 9218868437227405313))); print unpack("F", pack("h*", "1000000000000ff7")); do { print 'here' }; -e syntax OK C:\test>perl -MO=Deparse -le"use constant SNaN => unpack'd', pack'Q', +0x7ff0000000000001; print SNaN; if( SNaN == SNaN ) { print 'here'; }" BEGIN { $/ = "\n"; $\ = "\n"; } use constant ('SNaN', unpack('d', pack('Q', 9218868437227405313))); print unpack("F", pack("h*", "1000000000000ff7")); '???'; -e syntax OK

At first glance some will be surprised that it is the body of the equal (==) comparison that has been optimised away completely and the body of the unequal (!=) comparison that has been left behind but that isn't what impressed me. What did is this:

  1. At first I was a little disappointed to see that the unpack,pack, 'constant string' hadn't been reduced to a simple floating point constant the way 2*atan(1,0) above was.

    But then I realised that there isn't a floating point constant that can be embedded as source code that will translate to SNAN. That's why I need to use pack/unpack to define it.

  2. But the real surprise was that the optimiser recognised that SNaN == SNaN is the (*)one time when constant == constant is false!

    And then performs the appropriate optimisation; the inverse to the normal case.

So I wonder, is this special cased in the interpreter? A product of thorough, good design? Or simply fortuitous?

I did start to explore the source, but quickly got lost. Anyone know?


With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.

Replies are listed 'Best First'.
Re: Clever optimisation: by design or luck?
by dave_the_m (Monsignor) on Jun 25, 2016 at 09:09 UTC
    The constant folder looks for expressions matching various criteria, and if found executes them, replacing that part of the parse tree with the result. So NaN != NaN isn't handled specially.

    Dave.

      It's really cool! Thanks for the clarification.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.
Re: Clever optimisation: by design or luck?
by Athanasius (Archbishop) on Jun 25, 2016 at 09:25 UTC

    Hello BrowserUk,

    At first glance some will be surprised that it is the body of the equal (==) comparison that has been optimised away completely and the body of the unequal (!=) comparison that has been left behind...

    Yes, I was, until I found it documented in perlop#Equality-Operators:

    If your platform supports NaN 's (not-a-numbers) as numeric values, using them with "<=>" returns undef. NaN is not "<", "==", ">", "<=" or ">=" anything (even NaN), so those 5 return false. NaN != NaN returns true, as does NaN != anything else. If your platform doesn't support NaN 's then NaN is just a string with numeric value 0.

    I guess that’s logical: if something is not a number then using it in a numeric comparison doesn’t make much sense.

    But then I realised that there isn't a floating point constant that can be embedded as source code that will translate to SNAN. That's why I need to use pack/unpack to define it.

    I note that on my system (Windows 8.1, Strawberry Perl 5.24.0, 64-bit, with USE_LONG_DOUBLE defined) the call to pack is also optimised away:

    Hope that’s of interest,

    Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Re: Clever optimisation: by design or luck?
by shawnhcorey (Friar) on Jun 25, 2016 at 12:17 UTC

      Indeed. Also, I think it reads particularly nicely using

      ... DEBUG and print 'debugging'; ...

      Which achieves the same optimisation in a single line:

      C:\test>perl -le"use constant DEBUG=>0; print 'hi'; DEBUG and print 'd +ebugging'; print 'bye'" hi bye C:\test>perl -MO=Deparse -le"use constant DEBUG=>0; print 'hi'; DEBUG +and print 'debugging'; print 'bye'" BEGIN { $/ = "\n"; $\ = "\n"; } use constant ('DEBUG', 0); print 'hi'; '???'; print 'bye'; -e syntax OK

      And you can take it a step further if you add -s to your shebang line as I habitually do, and avoid even having to edit the script to enable the debugging (note the order of the pragmas!):

      #! perl -slw use constant DEBUG => $DEBUG; use strict; print 'hi'; DEBUG and print 'debugging'; print 'bye'; __END__ C:\test>t-debug.pl hi bye C:\test>t-debug.pl -DEBUG hi debugging bye C:\test>perl -MO=Deparse t-debug.pl BEGIN { $^W = 1; } BEGIN { $/ = "\n"; $\ = "\n"; } use constant ('DEBUG', $DEBUG); use strict 'refs'; print 'hi'; '???'; print 'bye'; C:\test>perl -MO=Deparse t-debug.pl -DEBUG BEGIN { $^W = 1; } BEGIN { $/ = "\n"; $\ = "\n"; } use constant ('DEBUG', $DEBUG); use strict 'refs'; print 'hi'; print 'debugging'; print 'bye';

      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice. Not understood.