Get rid of type-level logic

[jrudolph]

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]

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]

Here's a simple example that demonstrates a macro that helps with type-inference: jrudolph/whitebox-test@662b082

[lihaoyi]

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