On 29 January 2017 at 15:57, Hugo van der Sanden via RT <perlbug-followup@perl.org> wrote: > What I'd really like to do is reduce the amount of spooky action at a distance. Any time we find something that breaks unexpectedly, I'd rather think about how we can make things behave in a less unexpected manner than just put comments in - it's real hard to find a sane place to put such information that actually guarantees it'll be seen by someone trying to change the code in ways they might otherwise reasonably expect to be safe. > > I was hoping we'd have made more progress towards compiling to an AST by now, which was what prompted my initial work on the study_chunk branch, but I guess you haven't had time to progress on that. > > Whether a runtime check is suitable in this case or not, as a general principle I expect that the process of untangling the mess we have right now might incur small short-term performance costs; but that that's worth it in the expectation that once we have a clue what's going on we'll be able to implement better optimizations more easily. Ok, so lets put that kind of restructuring onto the backburner for when we do untangle the unholy mess that is study_chunk and regcomp.c For what it is worth I am very sympathetic to your intentions here, just not the immediate manifestation for this bug right now. Anybody adding features to the regex engine should be doing it under debugging, so if they break that code the assert will fire, they will see the comment and fix it. In the long run however you are quite correct that a proper AST and peephole optimiser and etc, would make a lot of the hackery involved here go away and be replaced by sensible and understandable code. So lets park this for now, and see where we get with that. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"Thread Previous | Thread Next