Re: Why context-free?

Neelakantan Krishnaswami <neelk@cs.cmu.edu>
13 Oct 2005 20:37:50 -0400

          From comp.compilers

Related articles
[9 earlier articles]
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-09)
Re: Why context-free? rfigura@erbse.azagtoth.de (Robert Figura) (2005-10-10)
Re: Why context-free? boldyrev@cgitftp.uiggm.nsc.ru (Ivan Boldyrev) (2005-10-10)
Re: Why context-free? dot@dotat.at (Tony Finch) (2005-10-13)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-13)
Re: Why context-free? cfc@world.std.com (Chris F Clark) (2005-10-13)
Re: Why context-free? neelk@cs.cmu.edu (Neelakantan Krishnaswami) (2005-10-13)
Re: Why context-free? darius@raincode.com (Darius Blasband) (2005-10-13)
Re: Why context-free? anton@mips.complang.tuwien.ac.at (2005-10-14)
Re: Why context-free? darius@raincode.com (Darius Blasband) (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-19)
Re: Why context-free? nmm1@cus.cam.ac.uk (2005-10-20)
[11 later articles]
| List of all articles for this month |

From: Neelakantan Krishnaswami <neelk@cs.cmu.edu>
Newsgroups: comp.compilers
Date: 13 Oct 2005 20:37:50 -0400
Organization: Carnegie Mellon Univ. -- Computer Science Dept.
References: 05-10-053
Keywords: parse, syntax

Nick Maclaren wrote:
> I have been thinking about a programming language, and have good
> reasons to abandon context-free grammars completely. So what I am
> asking is what reasons are there to favour them - I know of the
> following:
>
> 1) Dogma. Let's skip that.
>
> 2) Efficient, easy to write parsers. That is no longer a major
> issue, and I can deliver that in other ways.
>
> 3) Diagnosability of errors. I can deliver that in other ways.
>
> So WHY should I use a context-free grammar? Good reasons appreciated.


The language your compiler accepts /already/ isn't context free, if it
checks that variables are bound and that expressions typecheck -- ie,
the set of strings that the compiler will do other than emit an error
on is not context free.


Splitting the task of parsing into phases -- a) lexing, b) parsing,
and c) type-checking -- is just plain old good engineering. Each phase
creates stronger invariants on the things it passes on to the next, so
that writing them is easier. It's easier to form an AST when you know
what's a keyword and what's not. It's easier to typecheck a program
when you know your input is an abstract syntax tree -- your
typechecker doesn't have to have cases for what to do if a paren
doesn't have a closing brace. Making each phase simpler, makes it
easier to understand and debug, and yields more modular and
maintainable code.




--
Neel Krishnaswami
neelk@cs.cmu.edu


Post a followup to this message

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