Well, this is a leading question, and should be rejected by the judge!
I.e, the answer is yes, AND there isn't any significant work involved
in writing a parser.
> whatever crazy changes might happen (an AI parser), and get a
> result that is very slow. No thanks. Dumb parsing is slow enough.
Parsing is very fast, as any measurement will show. You are just
ill-informed (and wrong) here. See, for example (with apologies, since
I don't know any other reference offhand, and I'm too hot) my article
in Software Practice and Experience in nov. 1995: A PREttier
Compiler-Compiler: Generating higher order parsers in C. Perhaps you
are thinking of regular expressions and lexing?
You are simply expressing the misconception of which I complained. If
you don't know how to write a parser simply and quickly, you should say
so, and complain about that instead! So the colleges aren't teaching
the stuff that's well-known .. ;-)
Linus produced a good example of fast snappy parsing via a simple state
machine when he did the dependencies speedup code.
Perhaps one thing people need is a dynamically configurable command
line parser, like regexec, except that it takes a grammar as a -e option
and then filters the input against that. There are already a few such
things (tcl's regexp?). I just had a 5 minute try at implementing a
dynamically cionfigurable parser as a shell script. Looks like it works
(i.e. it parsed abcabab OK when I told it to!). One more thing for the
TODO queue.
> Spelling fixes are good. Grammar fixes are mostly useless.
> ASCII is ASCIIZ in the C language, so the distinction is useless.
Semantically true.
later/cheers/gesundheit (what DO these trailing greetings that I always
see really mean? - I love DM's "later"! It can be translated as anything
from "go to hell" to "pardon me for living")
Peter ptb@it.uc3m.es
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu