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) |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.