atom feed18 messages in org.perl.perl5-portersan actual start at fixing ~~
FromSent OnAttachments
Jesse LuehrsJul 8, 2011 10:21 pm 
Jesse VincentJul 8, 2011 11:00 pm 
Leon TimmermansJul 9, 2011 1:07 am 
Leon TimmermansJul 9, 2011 1:15 am 
Jesse LuehrsJul 9, 2011 1:34 pm 
Jesse LuehrsJul 9, 2011 1:37 pm 
Reverend ChipJul 10, 2011 2:45 am 
Leon TimmermansJul 10, 2011 4:40 am 
ZeframJul 11, 2011 4:41 am 
Jesse LuehrsJul 11, 2011 7:59 am 
Reverend ChipJul 13, 2011 2:38 pm 
Jesse LuehrsJul 13, 2011 2:41 pm 
Reverend ChipJul 13, 2011 2:57 pm 
ZeframJul 13, 2011 3:32 pm 
Reverend ChipJul 13, 2011 3:34 pm 
ZeframJul 14, 2011 12:06 am 
Jesse LuehrsJun 23, 2012 4:39 pm 
Ricardo SignesJun 24, 2012 5:28 am 
Subject:an actual start at fixing ~~
From:Jesse Luehrs (
Date:Jul 8, 2011 10:21:42 pm

So in the spirit of Jesse's talk at YAPC::NA, I decided to take a stab at seeing what would be involved in moving the existing smart match implementation out to a module, to free up the path for a better implementation in the future. As it turns out (due in large part to Zefram++), this was much easier than I was expecting. I've just shipped two trial dists to CPAN: smartmatch and smartmatch::engine::core.

smartmatch is a pragma that overrides the behavior of ~~ in a given lexical scope. You can pass a coderef or the name of an engine to 'use', and that code will be run to determine the result of any smart matches that occur. This uses B::Hooks::OP::Check to replace instances of OP_SMARTMATCH with instances of OP_ENTERSUB pointing to the given coderef.

smartmatch::engine::core is an implementation of the existing smart match algorithm, in module form. It has a pure perl implementation (which was certainly educational to write), but it also (unless specifically requested not to) sets a call check hook on that sub, which replaces calls to that sub with a custom opcode, using an implementation that was copied and pasted from the existing in-core implementation (pp_smartmatch), meaning that using this module should be indistinguishable from existing core behavior at runtime.

As for moving forward, I've started sketching out an implementation of Ricardo's proposed algorithm, which I've put up on Github for now. Any comments or suggestions for any of this stuff is more than welcome.


Relevant links: - - -