parboiled2 icon indicating copy to clipboard operation
parboiled2 copied to clipboard

Get rid of type-level logic

Open jrudolph opened this issue 10 years ago • 3 comments

Currently, parboiled2 uses two complementary compile-time mechanisms to make sure a parser is well-formed:

  • first, pretty advanced type-level logic is used to make sure that parsers were combined correctly
  • second, the parser generation macro either ignores the results of the type-level logic or deconstructs the implicit invocations inferred by the type-level logic to plug things together. It also checks that only "supported constructs" are used.

One major problem with the type-level logic approach is that (as @lihaoyi remarked) the compiler produces very generic error messages that often aren't helpful enough to fix a problem or even distract from the real issue.

My (somewhat heretical) suggestion is to completely get rid of the advanced type-level logic and replace it by simple macro-based logic. This could work roughly like this:

  • Keep the Rule types which work with HLists as marker types to be able to define the expected type of a rule.
  • Remove the implicit constraints on the combinators (like RunResult, TailSwitch etc.)
  • In the parser macro analyze the types of components to implement similar constraints like RunResult, TailSwitch, etc. did before but in actual compile-time macro logic. Also, the macro needs to actually infer the type of a rule. Some helper functions for working with types (like calculating lubs, etc.) will be needed but afterwards the actual logic could be quite straight-forward and easier to understand than the current type-level implementation.
  • In cases where the constraints aren't met try to report errors in a more helpful and concrete way.

This is not a small change but it may be worthwhile in the long run.

jrudolph avatar Nov 11 '14 08:11 jrudolph

I discussed this with @sirthias and one problem that is currently solved by type-level logic is type-inference inside a rule so that types for actions are properly inferred so that e.g. an action like _ + _ is valid if there are two Ints on the stack. To keep this in my proposed design also all of the combinators need to whitebox macros as well, so that they can help with type-inference.

jrudolph avatar Nov 11 '14 09:11 jrudolph

Here's a simple example that demonstrates a macro that helps with type-inference: https://github.com/jrudolph/whitebox-test/commit/662b0820f111f2bdc33e4e25c6d05a3b4bf9aa6c

jrudolph avatar Nov 11 '14 10:11 jrudolph

FWIW, here is a sample error message, just to motivate the issue ^_^ This particular one came from a missing ~

screen shot 2014-11-25 at 2 53 56 am

lihaoyi avatar Nov 25 '14 10:11 lihaoyi