Re: Parser Combinator in SML -- Problem with MLton

> fun expr _ = exprAdd ()
> and exprAdd _ = sop #"+" (op +) exprMul
> and exprMul _ = sop #"*" (op *) exprBase
> and exprBase _ = "expression expected" !!
>             trim (item #"(") >> expr() -- trim (item #")")
>          || trim number

From some more investigation, I now have the impression that the main
problem is not the parsing process itself, but the construction of the
parsers (in the above example 'expr()'). For instance, the construction
of the top-level parser takes MLton 130ms in my case. But the
constructed parser will still contain parts inside an unevaluated "fn _
=> ". And my guess is: Evaluating those throughout the parsing process
is the expensive part.

This was not a problem with the old approach, as a parser then was in
essence only 'bind closure closure', which is easy to evaluate and the
closures are only evaluated as needed.

@Matthew: It seems I cannot build a 'small' example. Should I share my
two versions of the parser (each version about 2000 loc) with you? Or is
this too much input to handle?

- René
-- 
René Neumann

Institut für Informatik (I7)
Technische Universität München
Boltzmannstr. 3
85748 Garching b. München

Tel: +49-89-289-17232
Office: MI 03.11.055

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

_______________________________________________
MLton-user mailing list
[email protected]; [email protected]
https://lists.sourceforge.net/lists/listinfo/mlton-user