George Russell wrote:
> [...] So far we've established that Happy is unnecessarily slow.

To be convinced about that, I still need to see some correct figures:

   * Detailed timing how long *parsing* Haskell with the Happy
     generated parser needs (excluding the time for lexing and
     the semantic actions on the RHS of the productions).

   * Comparing the speeds of parsers for different languages is bogus,
     e.g. I bet a drink that the majority of the time spent in the
     frontend is taken by the lexer and the associated bookkeeping
     needed for the layout rule. This rule is absent in ML, at the
     cost of some additional syntactic clutter.

   * I simply can't trust measurements with real time much larger
     than (user + sys). [ This has been fixed in a mail some minutes
     ago, but anyway. Otherwise one is probably benchmarking the
     OS and the CPU's cache, not the parser. ]

> Parser combinators don't actually seem to analyse the grammar at
> compile time at all, and instead just try all possibilities.

Parser combinators need not necessarily do any form of backtracking.

> Error correction was hopeless.

Not necessarily true again.

> And worst of all, there were a number of lurking ambiguities in the
> grammar which weren't discovered until it was exposed to the rigour
> of LALR parsing.

IMHO languages *designers* should use grammar tools in the first
place. Language constructs which are hard for computers (e.g. non-LR(k)
things) are even harder for the users of the languages. I'm pretty
sure another syntax for e.g. contexts would have been chosen if a
parser generator was used in Haskell's design stage. Quiz: When can
you decide that the opening parentheses start a tuple or a context? :-}

   foo :: (Baz a, Baz a)
   bar :: (Baz a, Baz a) => [a] -> [a] -> [a]

Another source of ugliness in the implementation of any Haskell
parser will probably be the longest-parse rule. Another quiz: Put
semantic-preserving parentheses around the following expressions:

   if x then y else z + 1
   if x then y else z :: T

Cheers,
   Sven
-- 
Sven Panne                                        Tel.: +49/89/2178-2235
LMU, Institut fuer Informatik                     FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen              Oettingenstr. 67
mailto:[EMAIL PROTECTED]            D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne

Reply via email to