Front page | perl.perl5.porters |
Postings from September 2011
A summary of Chip patches and potential impact
Thread Next
From:
Reverend Chip
Date:
September 2, 2011 13:50
Subject:
A summary of Chip patches and potential impact
Message ID:
4E61413C.9050000@gmail.com
To accompany Jesse's efforts to explain what makes a patch acceptable -- and I really like the phrase "free as in puppies" -- I wrote the below summary of the changes I have pending. Steffen++ is CPAN smoking the magic flags patch; some of the other patches need CPAN smoking too.
1. The biggest and most likely to cause trouble is the magic flags
patch, which ironically has almost no user-visible effects except better
control of FETCH timing; but it makes some of the core cleaner and helps
certain optimizations happen in more places. IIRC the .t changes required
were either zero or a slight improvement, i.e. magic FETCHes happened more
consistently and got reported better. The change at C level is _potential_
breakage of a pretty serious level if not everything is done right. Dragons
indeed hover around this one, but I think I've got them fully caged.
2. The second biggest change is the change to cached string conversions
so they're POKp but not POK, which enables us to distinguish strings
from numbers. That change is very unlikely to break anything, and
unlikely to change anything visible. This is a borderline case for CPAN
smoking.
3. Then there's the propagation of the boolean-ness of copies of sv_true
and sv_false. I can't imagine that would break *anything*; the layout
of the SVs remains the same. The only special thing is the setting of
SvPVX() to specific pointer values. Worst case, somebody somewhere is
making copies that wouldn't preserve boolean-ness. Who cares, that's fine.
(It's actually a teeny tiny performance improvement because copies of true
and false no longer call malloc/free to hold their "1" and "".)
4. The least problematic change, structurally, is the making visible of
the previous patches in C as SvIsBOOLEAN, SvIsNUMBER, and SvIsSTRING.
BUT: If the magic flags patch is not accepted, then either this won't
work right with magical values (including tainted values) *or* magical
values will not be allowed to cache their string conversions *or* I'm
going to have to introduce some new MAGIC magic just to provide an
alternative, MAGIC-friendly way to cache conversions. I just thought
of that last one, and I hope I don't have to write it, because I know
how, and I know I won't enjoy it much.
5. How we reveal isboolean, isnumber, and isstring to the users is an
interesting question. Scalar::Util functions as I've written are a gimme.
Making ~~ sane is obvious. Beyond that, we're going to get bikeshedded
to hell and back. scalartype()? Conversion functions? Boolean keywords?
Blargh. That's why I'm not going there myself yet, though I have a few
suggestions when the time comes. (Cogito, ergo bikeshedo.)
6. The odd patch out here is minimal copying, which isn't done yet, and
is unrelated to the other changes. It probably needs CPAN smoke too, but
it promises to reduce perl5's memory footprint - a legitimate gripe people
have against the language, and worth some effort to address.
7+. I've had some thoughts on reducing the size of CVs, HVs generally, and
stashes specifically. Also pads need to get out of CVs. And Mark Lehmann
has made some suggestions for core speed improvements that deserve attention.
Don't tell my GF, she thinks I'm on a core hacking sabbatical.
As for fears of the scalartypes patch being "yet another" type system, that's
FUD. Perl started out pretending that it could pretend that strings and numbers
had the same basic nature, and finally I think we should admit that it's not
working out 100%. Scalars already have several fundamentally distinct types
of content (undef, reference, glob, string+number); providing a bit more detail
on one of those existing types is not a new type system, it's just a finer view
on the existing system. And it seems like an obvious step toward running Perl
on systems where strings and numbers are very different.
Thread Next
-
A summary of Chip patches and potential impact
by Reverend Chip