Related articles |
---|
EBNF vbdis@aol.com (2004-11-20) |
Re: EBNF nkavv@skiathos.physics.auth.gr (2004-11-28) |
Re: EBNF martin@cs.uu.nl (Martin Bravenboer) (2004-11-28) |
Re: EBNF vbdis@aol.com (2004-12-01) |
Re: EBNF henry@spsystems.net (2004-12-11) |
Re: EBNF vidar@hokstad.name (Vidar Hokstad) (2004-12-16) |
Re: EBNF cfc@shell01.TheWorld.com (Chris F Clark) (2004-12-17) |
From: | henry@spsystems.net (Henry Spencer) |
Newsgroups: | comp.compilers |
Date: | 11 Dec 2004 12:24:57 -0500 |
Organization: | SP Systems, Toronto, Canada |
References: | 04-11-089 04-11-111 |
Keywords: | syntax, design |
Posted-Date: | 11 Dec 2004 12:24:56 EST |
Martin Bravenboer <martin@cs.uu.nl> 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 | henry@spsystems.net
Return to the
comp.compilers page.
Search the
comp.compilers archives again.