Re: Inherited attributes in available LALR parser generators?

torbenm@diku.dk (Torben AEgidius Mogensen)
Fri, 8 Oct 1993 10:27:17 GMT

          From comp.compilers

Related articles
Inherited attributes in available LALR parser generators? sperber@midi.informatik.uni-tuebingen.de) (1993-10-06)
Re: Inherited attributes in available LALR parser generators? parrt@s1.arc.umn.edu (Terence Parr) (1993-10-07)
Re: Inherited attributes in available LALR parser generators? torbenm@diku.dk (1993-10-08)
Re: Inherited attributes in available LALR parser generators? sperber@midi.informatik.uni-tuebingen.de (1993-10-09)
Re: Inherited attributes in available LALR parser generators? sassa@is.titech.ac.jp (Masataka Sassa 202 3228) (1993-10-13)
Re: Inherited attributes in available LALR parser generators? bombadil@diku.dk (1993-10-14)
| List of all articles for this month |
Newsgroups: comp.compilers
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Keywords: attribute, LALR
Organization: Department of Computer Science, U of Copenhagen
References: 93-10-035
Date: Fri, 8 Oct 1993 10:27:17 GMT

sperber@midi.informatik.uni-tuebingen.de) writes:
>... I'd be especially interested in purely functional variants.


I have written a SLR parser generator in Gofer (a Haskell variant) that
generates purely functional parsers (also in Gofer). Even though the
sematic value of a production is a function of the attributes of its
right-hand side (and thus apparently purely synthesized), inherited
attributes are easily simulated by using higher order functions. An
example from the manual is


Exp -> letT var equals Exp inT Exp
                                                                $ \env-> x6 ((x2,x4 env):env) $
          | Exp1 $ x1 $


Exp1 -> Exp1 plus Term $ \env-> x1 env + x3 env $
            | Exp1 minus Term $ \env-> x1 env - x3 env $
            | Term $ x1 $


Term -> Term times Factor $ \env-> x1 env * x3 env $
            | Term divide Factor $ \env-> x1 env / x3 env $
            | Factor $ x1 $


Factor -> integer $ \env-> intval x1 $
                | var $ \env-> lookup x1 env $
                | lpar Exp rpar $ x2 $




The semantic `function' is given in $...$ after the production. The
variables x1 ... xn refer to the semantic values of the 1st to nth
symbol on the right-hand side (like $0 to $n in yacc).


In this example the type of a semantic value is


environment -> value


where environment = [(name,value)]. In this way, the environment is an
inherited attribute and is thus given as argument to the semantic
functions of the right-hand side nonterminals.


You can have any number of synthesized and inherited attributes and
you don't have to worry about the order of attribute evaluation, since
the underlying language is lazy. I have even used recursively defined
attributes in some examples.


The parser generator is available by anonymous ftp from ftp.diku.dk in
the directory pub/diku/dists, in the file Ratatosk.tar.Z. Unpack this
by


                uncompress < Ratatosk.tar.Z | tar xvpf -


which creates a directory Ratatosk, containing the system.


The package contains a manual, sources for the parser generator and
scanner generator and some example files, including files for
bootstrapping the system.


Torben Mogensen (torbenm@diku.dk)
--


Post a followup to this message

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