Front page | perl.perl5.porters |
Postings from January 2018
On Thu, 18 Jan 2018 13:24:42 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:
> I'm going to experiment with hooking the opchecker for OP_LEAVESUB to
> see if that's another way to implement this. If that works, then I'll
> probably stick with that instead of my current attempt, because then
> it automatically works for 5.20 to 5.26, in addition to whatever
> future perl version eventually provides direct parser APIs for
> signatures or attributes.
It turns out this doesn't look likely to help.
In my current code, I am responsible for calling start_subparse(),
among whose responsibilities is to allocate the new CV and set it into
PL_compcv. Immediately after I call this I can then inspect the value
of PL_compcv and set it into the lexical hints hash, so that other
stages of the parser logic can compare whether they're still operating
on the actual `async sub`, or some nested (normal synchronous) `sub`
within it. If I just get the parser to handle the entire
`sub NAME (SIGNATURE) :ATTRS... {BLOCK}` part, then I lose the ability
to see PL_compcv directly, so this stops working.
I've thought up a few possible approaches into that which involve
remembering the height of the save stack and the observation that in
the current code, the value of the new PL_compcv gets pushed a certain
height above that, so maybe it could be recovered that way. But frankly
that way sounds massively fragile, even moreso than any other approach
I have here. So I don't think I'll do that.
I'm still quite attracted by the idea of getting perl to somehow do the
bulk of all the parsing for me, because otherwise I will have to write
quite a long and delicate sequence of looking for all the pieces, in
the right order, and stringing them all together nicely. It feels like
perl ought to be able to do that for me. I wonder if there'd still be
a way to make that work.
For example, if I could create the new CV and then pass that *in* to
the parser somehow, so that start_subblock() can use it, then I can
know what its value will be beforehand and set things up. That would
make things work while also not needing me to worry about how to drive
all the parser pieces.
This still wouldn't fix the gap between 5.20 and 5.{whatever
version this arrives in}, but it would at least be a start to ensuring
subsequent ones work OK, and maybe I can do something special and
custom to fill in the gap.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Thread Previous
|
Thread Next