From 514e62e37b812971a6aecaf30b28be6f6c8498b8 Mon Sep 17 00:00:00 2001 From: Father Chrysostomos Date: Tue, 7 Jun 2016 14:36:58 -0700 Subject: [PATCH] Porting/todo.pod: refaliasing needs fixing still MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit I don’t know when I’ll be able to get to this. This seems like a good place to jot down the ideas that existed only in my head till now. --- Porting/todo.pod | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/Porting/todo.pod b/Porting/todo.pod index d7d4dd5..f0f01cb 100644 --- a/Porting/todo.pod +++ b/Porting/todo.pod @@ -868,6 +868,35 @@ also the warning messages (see L, F). These tasks would need C knowledge, and knowledge of how the interpreter works, or a willingness to learn. +=head2 fix refaliasing with nested and recursive subroutines + +Currently aliasing lexical variables via reference only applies to the +current subroutine, and does not propagate to inner closures, nor does +aliasing of outer variables within closures propagate to the outer +subroutine. This is because each subroutine has its own lexical pad and the +aliasing works by changing which SV the pad points to. + +One possible way to fix this would be to create new ops for accessing +variables that are closed over. So C would use a new op +type, say C, instead of the C currently used in the +sub. That new op would possibly check a flag or some such and see if it +needs to fetch the variable from an outer pad. If we follow this approach, +it should be possible at compile time to detect cases where the more +complex C op is unnecessary and revert back to the simpler, +faster C. There would need to be corresponding ops for arrays, +hashes, and subs, too. + +There is also a related issue with recursion and C variables. A +subroutine actually has a list of lexical pads, each one used at a +different recursion level. If a C variable is aliased to another +variable after a recursive call to the same subroutine, that higher call +depth will not see the effect of aliasing, because the second pad will have +been created already. Similarly, aliasing a state variable within a +recursive call will not affect outer calls, even though all call depths are +supposed to share the same C variables. + +Both of these bugs affect C aliasing, too. + =head2 forbid labels with keyword names Currently C "computes" the label value: -- 1.8.3.1