On Tue, Aug 18, 2009 at 1:27 AM, Maurício<mauricio.antu...@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.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
