Front page | perl.perl5.porters |
Postings from August 2010
On 4 August 2010 15:47, karl williamson <public@khwilliamson.com> wrote:
> demerphq wrote:
>>
>> On 1 August 2010 21:19, Father Chrysostomos <sprout@cpan.org> wrote:
>>>
>>> A slightly simpler case:
>>>
>>> $ perl -le '$_="CCCGGG"; s!.!@a{print("[$&]"),/./}!g'
>>> [C]
>>> [C]
>>> [C]
>>> [C]
>>> [C]
>>> [C]
>>>
>>> What’s happening is that the s/// does not reset PL_curpm for each
>>> iteration, because it doesn’t usually have to.
>>>
>>> The RHS’s scoping takes care of it most of the time. This happens with
>>> the /e modifier and with @{...}.
>>>
>>> In this example, though, we have a subscript, not a block. This subscript
>>> is in the same scope as the s/// itself.
>>>
>>> The assumption that the substitution operator will never have to reset
>>> PL_curpm itself appears to be incorrect. The attached patch fixes it.
>>
>> Hi, thanks for the patch. Im a little concerned that this might have
>> deeper consequences than at first meet the eye, could we hold off on
>> this one until we know more?
>
> How will we find out more?
The problem is that there is a lot of code around that tries to deal
with various logical inconsistancies related to qr// and PL_curpm, and
the code is not obvious or intuitive.
So, for instance I am wondering what happens with this patch and
things like recursive patterns on the LHS, or things like that.
PL_curpm and everything related to it really deserves some deep
analysis and some love.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next