9 Jun
2015
9 Jun
'15
6:22 a.m.
Hi Roland, On 2015-06-09 07:03, Roland Bock wrote: >> What might be done based on your portable static assertion approach >> is adding a static method to these error classes representing the >> compilation errors to "static assert themselves" with better error >> messages. My concern about this is loosing the details of the error >> (position in the parsed text, the range boundaries and the index in >> case of an out of range error, etc). I'll check if "static assert >> yourself" can be done without loosing that information. > I had similar concerns at the beginning. It turned out (at least in my > case) that the "lost information" > > * might be relevant for the developer of the library > * was just hiding the relevant things from the user > > Whether the same is true for Metaparse, I don't know. In case of Metaparse the information lost there is important for the users of the parsers. It has the answers to questions like: - where (in the DSL script) is the error coming from? (column, maybe line number) - information that is a template argument of a parser combinator. For example: when the parser finds a different character than what was expected in the DSL script, what was the expected character? eg. when the parser is parsing "()" or "[]" pairs and is waiting for the closing element, etc. In those cases the expected characters are template arguments, not hard-coded values of the parsers (and parser combinators) the library offers. And they should be part of the error report. Regards, Ábel