`_get_lexer_callbacks` not defined

[guyvdbroeck]

Running a local copy of https://github.com/jamesrhester/Lerche.jl/blob/master/examples/calc.jl gives an error:

julia> include("calc.jl")
ERROR: LoadError: UndefVarError: _get_lexer_callbacks not defined
Stacktrace:
 [1] Lark(grammar::String, loptions::Dict{String, Any}, source::String, cache_file::String)
   @ Lerche ~/.julia/packages/Lerche/rO9vr/src/lark.jl:190
 [2] Lark(grammar::String; options::Base.Iterators.Pairs{Symbol, Any, Tuple{Symbol, Symbol}, NamedTuple{(:parser, :transformer), Tuple{String, CalculateTree}}})
   @ Lerche ~/.julia/packages/Lerche/rO9vr/src/lark.jl:121
 [3] top-level scope
   @ ~/.julia/dev/LogicCircuits/scratch/calc.jl:49
 [4] include(fname::String)
   @ Base.MainInclude ./client.jl:444
 [5] top-level scope
   @ REPL[3]:1

[jamesrhester]

Thanks for the bug report. which led me to a TODO statement. Currently automatic transformation immediately after parsing is not implemented ("transformer" option). That means that a call to Lark that sets the transformer option causes an error. I will see if I can find a quick fix. Meanwhile the workaround is to perform the transformation in a separate call (i.e. g = Lark(...);p = Lerche.parse(g,text); transform(x::MyType,p))

[guyvdbroeck]

Is there a performance cost to doing the transformation after parsing?

[erezsh]

@jamesrhester You can make Lerche.parse() do the transform, and in later versions embed it into the parse-tree-builder. The users don't have to know about it. (just my two cents)

[jamesrhester]

@guyvdbroeck the performance cost that I can see is a trade-off between traversing the parse tree a second time (a cost) but having a known type for the parse tree during parsing if no transformer is run during parse tree construction (a benefit). I'm thinking about ways in which this could be made more Julian, perhaps by providing a type parameter that fixes the output type of the transformer methods.

[jamesrhester]

@erezsh Yes that would fix it - the transform method is simply called as soon as parsing is complete.

[jamesrhester]

Commit 8872eb2 contains a fix for the include(calc.jl) issue. It simply transforms using the specified transformer following construction of the parse tree as suggested above. I'll issue a new release.