Re: EBNF

henry@spsystems.net (Henry Spencer)
11 Dec 2004 12:24:57 -0500

          From comp.compilers

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)
| List of all articles for this month |
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



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.