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

We're short on hints bits and feature bundles - possible ideas

Thread Next
Paul "LeoNerd" Evans
July 17, 2020 14:31
We're short on hints bits and feature bundles - possible ideas
Message ID:
The `PL_hints` variable currently has all 32 bits defined for various
purposes. Three of those bits encode the current "feature bundle". This
bundle can be default (currently empty), CUSTOM (meaning to look in the
'features' lexical hint), or one of 6 pre-defined bundles. Currently we
are using all 6 of these bundles. This means we cannot allocate a new
one. We would quite like a new bundle for the 5.33.x development
series, to experiment with removing `indirect` and `switch`, and other

Three possible solutions have been suggested. They are not mutually
exclusive; any or all of them could be used in combination:

  1) Don't generate a bundle for every numbered set  [LeoNerd]

     The bundles are really just a performance enhancement. Because
     CUSTOM exists it is always possible to make any specific
     combination of features; the bundles are just there to avoid a
     lookup into those bits in the common case of just pre-selecting
     one of the numbered bundles.

     If we wanted an easy fix without disturbing too much code, we could
     just start removing the oldest numbered bundles as shortcuts. The
     oldest is :5.10, so what we could do is have generate
     that not as a numbered bundle, but just apply it as CUSTOM + the
     individual bits.

  2) Recover one of the bits only used briefly by VMS  [ilmari]

     It turns out that VMS only briefly used the 0x20000000 bit, so
     there's room to widen the bundle mask by one bit┬╣, so that one
     could remove e.g. 'switch' and 'indirect' (and possibly
     'multidimensional', when that gets merged) from the 5.33 bundle┬▓.


  3) Move the three `HINTS_EXPLICIT_STRICT_` bits elsewhere  [LeoNerd]

     Another idea is to move the three HINTS_EXPLICIT_STRICT_* bits out
     of PL_hints into their own place. The only reason for their
     existence is to signal whether strict flags are on because of `use
     VERSION` or because of `use strict` - that way, a subsequent
     downgrading of `use v5` knows whether to turn them off again. These
     could easily be moved to a new variable for that purpose.

These solutions can combine - e.g. we could perform steps 2 and 3 and
recover four bits in total.

Opinions, anyone?

Paul "LeoNerd" Evans      |  |

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