Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!ll-xn!ames!umd5!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!uiucdcs!uiucdcsm!wsmith
From: wsmith@uiucdcsm.cs.uiuc.edu
Newsgroups: comp.lang.misc
Subject: Re: Block Closure (was Re: FOR loop
Message-ID: <5200004@uiucdcsm>
Date: 27 Apr 88 02:59:00 GMT
References: <2400015@otter.hple.hp.com>
Lines: 28
Nf-ID: #R:otter.hple.hp.com:2400015:uiucdcsm:5200004:000:1478
Nf-From: uiucdcsm.cs.uiuc.edu!wsmith    Apr 26 21:59:00 1988


An attribute grammar does not help the parsing problem.  At attribute
grammar takes a parse tree specified in a grammar G and decorates it
with information that may be calculated automatically from the structure
and terminals used in the parse tree.  Somehow the parse tree must
be created first.

The Cornell Synthesiser generator avoids the problem of parsing except
for regions such as expressions that are too difficult to enter except
through parsing.  By building a program generatively (by resolving one rule
at a time), one need not have an unambiguous concrete syntax.  Thus,
CPS could easily handle the indenting problem, but it creates a whole
additional set of issues in the process.

With a text file, the compiler must recognize the text of the program and
match it with rules commonly specified as two parts: a lexical analyzer and 
a parser.   With the Cornell Program Synthesizer, the semantics routines
do not need to do any recognition because the text is already matched with
the rules ahead of time.  

A compiler could use attribute grammars to do type checking
and code generation just as easily as the CPS.  They are really two
different issues:  How will the programming environment decide what a
programmer meant (by parsing the or by having the program entered
as templates)?  and how the environment will get meaning from the structure
(by using attribute grammars or some other ad hoc scheme)?

Bill Smith 	wsmith@a.cs.uiuc.edu	ihnp4!uiucdcs!wsmith