Related articles |
---|
The speed of an Earley parser? newspub@wuggy.co.uk (2001-06-17) |
Re: The speed of an Earley parser? sting@linguist.Dartmouth.EDU (Michael J. Fromberger) (2001-06-21) |
Re: The speed of an Earley parser? joachim_d@gmx.de (Joachim Durchholz) (2001-06-21) |
Re: The speed of an Earley parser? newspub@wuggy.co.uk (2001-06-28) |
Re: The speed of an Earley parser? idbaxter@semdesigns.com (Ira D. Baxter) (2001-07-02) |
Re: The speed of an Earley parser? news0@greynode.net (Benjamin S.Scarlet) (2001-08-06) |
Re: The speed of an Earley parser? Mark.van.den.Brand@cwi.nl (M.G.J. van den Brand) (2001-08-08) |
Re: The speed of an Earley parser? holzmueller@ics-ag.de (2001-08-15) |
From: | holzmueller@ics-ag.de (=?ISO-8859-1?Q?Bernd_Holzm=FCller?=) |
Newsgroups: | comp.compilers |
Date: | 15 Aug 2001 01:39:00 -0400 |
Organization: | http://groups.google.com/ |
References: | 01-06-041 01-08-027 01-08-049 |
Keywords: | parse, performance |
Posted-Date: | 15 Aug 2001 01:39:00 EDT |
I did parser construction (LL(k), LALR(k) using yacc, javacc, etc.)
quite extensively in the past and found parsing using a combinator
library with the functional language Haskell superior to what I knew
before. See www.haskell.org and the library named Parsec.
The advantages of combinator based parsing are manyfold: there is no
intermediate step to generate the parser (like yacc), no special
syntax, no "embedded" target code, it lets you define your own parser
combinators as you like, and allows context-free (kind of
EBNF-specified!) and even context-sensitive parsing (using
backtracking) but can be forced to be deterministic using special
combinators (that is, you have the choice for efficiency against
generality).
Of course, it's not as efficient as generated parsers are, but I found
it sufficiently fast for most purposes.
Bernd
Return to the
comp.compilers page.
Search the
comp.compilers archives again.