Let generated interpreters handle 'nothing' values.

[StefRasing]

Exception throwing and catching in Julia is really really slow. A better way to handle invalid arguments or parsing is to let domain functions return a special value in stead of throwing exceptions. I choose nothing as an exception, but we might use more informative exceptions.

To correctly pass exceptions upstream, the interpreter needs to return nothing if any child of the interpreted program produces nothing.

To give a sense of the speed-up this might give; a certain SyGuS string problem was solved in ±12s using the old interpreter, but with this fix it only took ±1s. This is a huge speedup, but the string domain is exception heavy. I don't think fix will harm performance in any other way.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.11%. Comparing base (b5a6c5c) to head (bdeae16).

Additional details and impacted files

@@           Coverage Diff           @@
##           master      #50   +/-   ##
=======================================
  Coverage   69.11%   69.11%           
=======================================
  Files           3        3           
  Lines         204      204           
=======================================
  Hits          141      141           
  Misses         63       63           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Benchmark Results

	master	bdeae16...	master / bdeae16...
interpret/Random Expressions	0.124 ± 0.0016 ms	0.124 ± 0.0017 ms	1 ± 0.019
time_to_load	0.0765 ± 0.00061 s	0.0776 ± 0.0017 s	0.986 ± 0.023

Benchmark Plots

A plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR.
Go to "Actions"->"Benchmark a pull request"->[the most recent run]->"Artifacts" (at the bottom).

[THinnerichs]

Thoughts:

1. I think moving to eager evaluation from lazy evaluation should not have an impact.
2. You use nothing to denote "An exception should have been thrown here". We should use a dedicated struct for this and wrap the result so we can dispatch over it:

module HerbInterpret
...

struct InterpretException <: Expception end

struct InterpretResult{R} ... end 
...
end

3. Note to myself:

• Update stateful formulation, too
• Double check whether this changes the interpretation of composites; understand why it doesn't.

[ReubenJ]

https://github.com/Herb-AI/HerbInterpret.jl/tree/bench/update-to-generated now includes examples of using the generated interpreters in the ./benchmark/benchmark.jl setup — just in case that's useful.