develooper Front page | perl.perl5.porters | Postings from April 2016

Re: [perl #127875] Blead breaks Scope::Upper

Thread Previous | Thread Next
Dave Mitchell
April 18, 2016 10:16
Re: [perl #127875] Blead breaks Scope::Upper
Message ID:
On Tue, Apr 12, 2016 at 07:45:12PM -0400, Ricardo Signes wrote:
> Still, there has to be a line drawn between what can be supported and what
> cannot, and right now that line is the public API.  It's not a great line.  We
> have talked about trying to improve it in the past, but so far nothing has
> actually been done.  What we've said in the past is that if you want to build
> something that you can rely on, by all means build it now, but then come to p5p
> and say, "Look, I made a thing.  This thing is useful.  I want to make sure it
> doesn't get broken in the future.  What can be done?"  (This gets to what was
> (b) in Tony's mail.)
> That shares the onerousness: some for p5p to provide a public API and some for
> the reporter to rework code to use it.

I've spent the last week doing more work on Scope::Upper. I have it down
to 6 failing test scripts out of 58. The main failures at the moment are
the uplevel ones - uplevel being a mechanism to run a sub apparently in a
higher scope. I don't think the current implementation is fixable and will
need to be done a different way, which I will need to think about. I also
haven't tried it on perls older than 5.23.7 (I've been testing using
5.23.7 and 5.23.8 as representing the pre- and post-context perls), so may
need more fixes to run on older perls.

But one thing that should be made clear; it isn't just the case that S::U
is doing something which relies on an internals-only API and that we have
the choice of making this API public; instead it is an inherently fragile
implementation that is extremely sensitive the exact details of how the
save stack is manipulated. It works by artificially altering the
boundaries of N parent savestack frames, then within each SAVEt_DESTRUCTOR
action called while freeing a savestack frame that has an artificially
increased lower bound, it itself frees the savestack items below that
higher threshold, then injects another SAVEt_DESTRUCTOR below that
threshold so that it appears to be in the caller's savestack frame. These
propagate on each scope exit until the desired scope level  is reached.

So I don't think there's any sensible API we could create that would
shield S::U from the details of perl's internals. Also, I don't think
S::U should be included in core. We should be discouraging this module's
use, not implicitly endorsing it.

Also, although I have been putting in considerable effort to fix this
module, I don't think I *should* have to do this, nor should it be
expected that p5p will do similar fixups in future.


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