I'm not actually facing a very specific problem. (Well, I am, but it's easy to solve without a parser.) I just have seen many situations where such parser could be usefull. I'll try some examples.
(1) You have a programming language you want to write a compiler for. You write a grammar for it. To test if this grammar actually works, you can run 1GB of code in that language throw that parser, and it will do or output something (maybe call printf) at specific matches. (2) You want to parser a natural language and test if a grammar works well. I don't know how parsing of natural languages is done, though. (3) You have lot of data that some program outputs and you want to read that output, but it has no clear structure. You could test a few grammars until you see you can extract information that is easier to deal with. One thing that is not clear to me is what would be an action to do when a match is found. I imagine a formated output could be okay, since that can be made into program calls if necessary. Thanks, Maurício
Can you expose a practical example of this? Maybe taking use cases as design roots we can catch a better idea of how to implement this or how to solve the problem you are facing.
Sure. I want something that helps testing and can deal with complex input, or even input with unknown structure to which you want to check if one works, even if temporarily. Example: someone gives you some unorganized data and you just want to transform it into something you can deal with.
>> (...)
However, "errors" in these tools should not be errors in a strict sense. I do want to write a tool that you can use to check grammar hyphotesis on text, and that means that even if you don't get fatal errors you still want to know how well your grammar did with some input, and get meaninfull report on, say, how long a match had to be to solve ambiguity, how deep an analysis had to be to find a match, which false matches were more common etc, and you want this report to be good for automated analysis.
