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

Is it time to separate pad names from SVs?

Thread Next
From:
Father Chrysostomos
Date:
October 30, 2014 15:25
Subject:
Is it time to separate pad names from SVs?
Message ID:
20141030152505.13408.qmail@lists-nntp.develooper.com
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
declared.

I.e.,

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

would return a constant sub.  But

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

and

    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.

Flags:

PADNAMEt_UTF8
PADNAMEt_FAKE/OUTER
PADNAMEt_STATE

Plus two new ones:

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


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About