Re: Why context-free?

Chris F Clark <>
13 Oct 2005 20:36:24 -0400

          From comp.compilers

Related articles
[8 earlier articles]
Re: Why context-free? (2005-10-09)
Re: Why context-free? (2005-10-09)
Re: Why context-free? (Robert Figura) (2005-10-10)
Re: Why context-free? (Ivan Boldyrev) (2005-10-10)
Re: Why context-free? (Tony Finch) (2005-10-13)
Re: Why context-free? (2005-10-13)
Re: Why context-free? (Chris F Clark) (2005-10-13)
Re: Why context-free? (Neelakantan Krishnaswami) (2005-10-13)
Re: Why context-free? (Darius Blasband) (2005-10-13)
Re: Why context-free? (2005-10-14)
Re: Why context-free? (Darius Blasband) (2005-10-19)
Re: Why context-free? (2005-10-19)
Re: Why context-free? (2005-10-19)
[12 later articles]
| List of all articles for this month |

From: Chris F Clark <>
Newsgroups: comp.compilers
Date: 13 Oct 2005 20:36:24 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 05-10-053 05-10-055 05-10-064 05-10-070
Keywords: parse, types
Posted-Date: 13 Oct 2005 20:36:24 EDT

Nick Maclaren wrote about using something to express type restrictions
in a new language he was designing, to which our esteemed moderator
John, wisely suggested:

> Use attributes. That's what they're for.

John, suggestion has a lot of merit, irrespective of error processing.

Atrributes (i.e. little expressions one adds to the grammar that
compute some context sensitive information) are a really good solution
to the problem of adding well-typed expressions to a grammar.

Trying to put types directly into a grammar is a disaster. It makes
the grammar grow exponentially. That's the general failure of VW
grammars--such grammars are a way of succinctly describing the
explosion. Unfortunately, when one is actually parsing with them, one
has to explode them.

In contrast, attribute expressions effectively become another pass.
One parses the grammar for some rough syntactic correctness using the
CFG. Then once, one has identified the expressions and their
syntactic structure, one walks the resulting tree (or dag) and
computes whether the types can be consistently applied. If one can,
one proceeds to the next step in compilation. If one can't, one can
issue a diagnostic that says, "This part of the expression looked like
it wanted to be this type (or set of types), but this part of the
expression wanted to be this type (or set), and the types are not
compatible, because the following rule is violated...."

The notation of attributes are even correct for expressing type
calculations. They really are calculations and generally form some
form of functional programing language. And, what one wants, as
described above is to "unify" two expressions. Unify meaning, can we
find a setting of the not yet defined values which makes this
expression consistent. This can be used to insert the implied
promotions, conversions, coercions, and/or casts which are used to
make the expression consistent. (And, if it were my language, I would
add a step (compiler output) which gave the fully disambiguated
expressions, so the user could verify that the right interpretation
was made, but that's another topic.)

Enough advice for one day.

Hope this helps,

Chris Clark Internet :
Compiler Resources, Inc. Web Site :
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)

Post a followup to this message

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