develooper Front page | perl.perl5.porters | Postings from October 2014

Is it time to separate pad names from SVs?

Thread Next
Father Chrysostomos
October 30, 2014 15:25
Is it time to separate pad names from SVs?
Message ID:
I am attempting to fix sub(){$outer_lexical} closure behaviour again,
but this time allowing the sub to be inlined if the variable is not
referenced or used as an lvalue in the outer sub except where it is


    my $x = whatever;
    sub () { $x }

would return a constant sub.  But

    my $x = whatever;
    sub () { $x }
    $x = something else;


    my $x = whatever;
    $sub1 = sub() { $x }
    $sub2 = sub { $x ++ }

would not.

But to make this work, I need two more flag bits in pad names.  There
are SV flag bits that are never used for pad names (e.g., SvTEMP), but
commandeering them for this purpose may slow down hot code paths else-
where, due to extra checks.

Separating pad names into their own type would give me plenty of room
for flags.  I think it would also save memory and make SV-handling
code simpler.  It would be something like this:

struct padname {
    char * xpadn_pv,
    HV *   xpadn_ourstash,
    HV *   xpadn_typestash, /* or a union with a lex proto CV */
    U32    xpadn_low,
    U32    xpadn_high,
    U16    xpadn_len, /* don't need more than 16 bits for a pad name */
    U16    xpadn_flags,

xpadn_pv would point just after the end of the struct, so the pad
name struct and the name buffer would be allocated together.  Pad
names without name buffers would have a null pointer.



Plus two new ones:

PADNAMEt_LVALUE      /* used as lvalue after declaration */
PADNAMEt_CLOSED_OVER /* any shorter name that is memorable? */

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