L-attribute grammars VS a more general class

locks@cs.sun.ac.za (Graeme Lockley)
Thu, 20 Aug 1992 14:35:42 GMT

          From comp.compilers

Related articles
L-attribute grammars VS a more general class locks@cs.sun.ac.za (1992-08-20)
| List of all articles for this month |

Newsgroups: comp.compilers
From: locks@cs.sun.ac.za (Graeme Lockley)
Organization: Compilers Central
Date: Thu, 20 Aug 1992 14:35:42 GMT
Keywords: attribute, question

This is a problem which has kept me thinking for a while now.


      The attribute grammar community can be roughly divided into two camps.
The first camp believe that L-attribute grammars are not only simple, but
are powerful enough to specify real programming languages. The second camp
refute this by expending a lot of resources towards building attribute
evaluators for the larger classes; pseudo-circular, non-circular, ordered
AG to name the most popular.


      My question is:
          Can languages that require identifiers be defined before use, be
          specified more compactly and/or clearly using the larger than
          L-attribute grammars?


    Should this be the case, then most modern languages (don't take the term
`modern' too literaly) can be specified using L-attribute grammars. The
languages I have in mind being Modula-2, K&R C and ANSI C (granted, the
PIM definition of Modula-2 does not allow the FORWARD keyword, although
most of the Modula-2 compilers require the FORWARD definition if a
procedure is used before being defined).


      I don't want to start a language or attribute grammar war; I am
primarily intrested in the benefits of using a general class of attribute
grammar above L-attribute grammar for the languages in question. A REAL
example accompanying each response would be greatly appreciated.


      Please don't respond to the net but post to my e-mail address. Should
anybody request for a summary, I'll post.


Graeme Lockley
--


Post a followup to this message

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