Re: [dev] Lexers and parsers

(2/2 - I believe these messages didn't went to
the list. Sorry if they actually did.)

>> (...) If you had such "shell yacc", how would you like it to be
>> or behave?

> (...) So the important thing is being able to whip something up
> quickly; this isn't parser "specs" that's going to be carefully
> developed and then used for a very long time.

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.

> A general point: one of the most important things to think
> about, particularly with parsers, is what would be most
> effective in tracking down the inevitable problems when there's
> a bug in the user input and/or mismatched input, particularly if
> it happens in the middle of a pipe process: how are you going to
> report which part of the input stream was wrong, particularly if
> it doesn't exist on its own, in a way which is effective for a
> human to track down the problem? (...)

The exact answer will probably depend on the chosen grammar type
and parsing algorithm. Allowing specified limits on match size or
deepness of analysis we could get error logs to be readable.

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.

Best,
Maurício
Received on Thu Aug 20 2009 - 15:31:50 UTC