Re: [dev] Lexers and parsers

On Tue, Aug 18, 2009 at 1:27 AM, Maurício<mauricio.antunes_AT_gmail.com> wrote:
> I've been thinking on how to implement such tool. Since I'm
> not a really good developer, I thought about asking people for
> sugestions. If you had such "shell yacc", how would you like it
> to be or behave? Would BNF be okay, or would you expect something
> different? Do you think mimicking lex and yacc as close as
> possible would be the best?

Assuming that I've got the point of your idea: it should be possible
to write parsers for more one-off problems that fit into unix pipes,
etc. 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.

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? My only
solution would be to have a logging mode on the parser which allows
saving all the input it receives to a file on disk. But that wouldn't
make me want to use an "on-the-fly" parser generator rather than a
more temporary file based approach, which was the point of the idea.
Not to say it's a conclusively an idea that won't work, just that a
good answer to that problem would be important for me to want to use
it.

-- 
cheers, dave tweed__________________________
computer vision reasearcher: david.tweed_AT_gmail.com
"while having code so boring anyone can maintain it, use Python." --
attempted insult seen on slashdot