Another way to do this is to have the Lark object (or interface) define the
event methods rather than have a separate Handler object. When it's time to
parse something, create a subclass that overrides the (standard) event methods
for the Lark object.
A possible advantage to this method is that it makes clear the inheritance
relationship between the "standard" parser and something more specific. It
is also "easier" to create a more specific parser from an exisiting parser
object - simply subclass the existing parser and override the methods
required to provide the desired new functionality.
The Lark model "hides" the inheritance relationship in the Handler object
making it necessary to look inside a Lark object to determine the type of
a given parser (something you might need to do when debugging). An
alternative is to create a new parser object that contains a subclassed event
handler. This makes it possible to distinguish the type of parser at the
"outer" level but requires two new objects instead of one to perform the
subclass.
I'm not a parser expert so the subclass model may not make any sense but this
is a mechanism I have successfully used building other object-oriented
(including GUI-based) systems. I have also used callbacks but find them most
useful when forced to use C or other non-object-based languages.