|EBNF email@example.com (2004-11-20)|
|Re: EBNF firstname.lastname@example.org (2004-11-28)|
|Re: EBNF email@example.com (Martin Bravenboer) (2004-11-28)|
|Re: EBNF firstname.lastname@example.org (2004-12-01)|
|Re: EBNF email@example.com (2004-12-11)|
|Re: EBNF firstname.lastname@example.org (Vidar Hokstad) (2004-12-16)|
|Re: EBNF cfc@shell01.TheWorld.com (Chris F Clark) (2004-12-17)|
|From:||email@example.com (Henry Spencer)|
|Date:||11 Dec 2004 12:24:57 -0500|
|Organization:||SP Systems, Toronto, Canada|
|Posted-Date:||11 Dec 2004 12:24:56 EST|
Martin Bravenboer <firstname.lastname@example.org> wrote:
>...This separation is inspired by performance concerns: by
>separating the input in tokens, the number of elements the parser has to
>consider is reduced.
It is also a very nice "separation of concerns", dividing the problem into
two steps and thus often making it easier to solve.
I have found a scanner/parser separation very useful even in problems
normally thought too simple to require it. Being able to work at two
separate levels often results in cleaner, more readable code and
simpler solutions to awkward problems.
>...The problem of using a separate
>scanner is that the context of the token in the input cannot be considered.
It is straightforward, in principle, for the parser to inform the scanner
about context. In practice, this is easy to implement with a recursive-
descent parser but rather harder with a parser generator, especially if
the parser generator uses bottom-up parsing (which typically knows less
about the context).
"Think outside the box -- the box isn't our friend." | Henry Spencer
-- George Herbert | email@example.com
Return to the
Search the comp.compilers archives again.