Re: Developing/inventing a grammar...

torbenm@app-0.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
12 Jul 2005 05:21:09 -0400

          From comp.compilers

Related articles
Developing/inventing a grammar... oliver@first.in-berlin.de (Oliver Bandel) (2005-07-11)
Re: Developing/inventing a grammar... cfc@shell01.TheWorld.com (Chris F Clark) (2005-07-12)
Re: Developing/inventing a grammar... makc.the.great@gmail.com (makc.the.great) (2005-07-12)
Re: Developing/inventing a grammar... torbenm@app-0.diku.dk (2005-07-12)
| List of all articles for this month |
From: torbenm@app-0.diku.dk (=?iso-8859-1?q?Torben_=C6gidius_Mogensen?=)
Newsgroups: comp.compilers
Date: 12 Jul 2005 05:21:09 -0400
Organization: Department of Computer Science, University of Copenhagen
References: 05-07-044
Keywords: parse, design
Posted-Date: 12 Jul 2005 05:21:09 EDT

Oliver Bandel <oliver@first.in-berlin.de> writes:


> Any hints for effectively developing a grammar for a tool where I have
> an idea about how the language could/should look like?
>
> I use lex & yacc, have an idea about what the tool/language should do.
>
> But how to clearly develop a grammar for this?
>
> It's a different task to develop a grammar from scratch then using an
> already existing grammar and implementing it with lex & yacc.
>
> Any hints on how to go that way? Any tools? Tips & Tricks?
>
> Where to start? Starting with the keywords and the precedences?


First write the grammer down as you would in the user documentation
(assuming users understand grammars). Don't worry (at this stage)
about ambiguity, and allow yourself to use shorthand such as "id *" or
"(e_1,...,e_n)".


Then write this grammer in the form required for the parsing tool,
naming lexical items and introducing auxiliary nonterminals for the
shorthand used above. Still don't worry about ambiguity.


Add operator precedence declarations for the obvious cases (arithmetic
operators etc.).


The run the parser generator with verbose output. Identify the causes
for conflicts and add more precedence declarations or rewrite to avoid
ambiguity. In most cases, precedence declarations will suffice, but
be careful to not exclude valid strings.


If you have some freedom in the exact look of the language, it may be
useful to add delimiting symbols (semicolons etc.) or keywords
("endif" etc.) to resolve ambiguities. But only add these where
necessary, or people will hate your language for being too verbose.


                Torben


Post a followup to this message

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