Path: news.iastate.edu!leavens
From: leavens@cs.iastate.edu (Gary T. Leavens)
Newsgroups: isu.coms.342
Subject: grammars for slists, symbol-expressions, and trees
Date: 17 Sep 1998 04:43:26 GMT
Organization: Iowa State University, Ames, Iowa, USA
Lines: 125
Message-ID: <6tq41e$otn$1@news.iastate.edu>
NNTP-Posting-Host: ren.cs.iastate.edu
Summary: follow a gramar
Keywords: s-list, symbol-expression, tree
X-Newsreader: NN version 6.5.1 (NOV)
Xref: news.iastate.edu isu.coms.342:573

A couple of students asked today in class about making procedures that
are based on a different grammar for s-lists, symbol-expressions.
I was also wearing a T-shirt that uses a different grammar (on the back :-),
so there may be some interest in describing some of these ideas.
Here's my thoughts on these.

Our book gives the following as the grammar for symbol-expressions and s-lists:

<s-list> ::= ( {<symbol-expression>}* )
<symbol-expression> ::= <symbol> | <s-list>

The question in class was, could we write these so that each kind
doesn't recurse to the other?  yes we can...

To rewrite these, we need to first change them to not use the
Klenee star:

<s-list> ::= () | ( <symbol-expression> . <s-list> )
<symbol-expression> ::= <symbol> | <s-list>

We can substitute the definition of <symbol-expression> into
the production for <s-list>, obtaining the following,
where I'm using | inside a production informally.

<s-list> ::= ()
          | ( { <symbol> | <s-list> } . <s-list> )

You could actually use that as a template for programming,
and it just gives you a nested if-expression.  But if want to use the
grammatical conventions we've seen in class, we would split the second
production into two parts, one for each alternative,
obtaining:

<s-list> ::= ()
          | ( <symbol> . <s-list> )
          | ( <s-list> . <s-list> )

(begin note which can be ignored)

If you have seen this before, you may recognize this as the type (tree symbol)
that I've used when I taught 227 in Scheme.  For this reason, I will often
call this the tree grammar.

<(tree T)> ::= ()
          | ( <T> . <(tree T)> )
          | ( <(tree T)> . <(tree T)> )

(end note which can be ignored)

Now, we could try the same trick with the s-expression grammar,
but here's what we get in one substitution:

<symbol-expression> ::= <symbol>
                    | { () | ( <symbol-expression> . <s-list> ) }

Splitting this up, we get:

<symbol-expression> ::= <symbol>
                    | ()
		    | ( <symbol-expression> . <s-list> )

The trouble is, unlike the grammar for <symbol-expression>,
the grammar for <s-list> is self-recursive, so this doesn't work well.
We could try substituting again, but then we'd just get.

<symbol-expression> ::= <symbol>
                    | ()
		    | ( <symbol-expression> . () )
		    | ( <symbol-expression> .
                                       ( <symbol-expression> . <s-list> ))

But all isn't lost.  Tinnk of what the limit of this process is.
Or, if you don't like limits (sounds too much like calculus :-),
we could go back to the original production for
<s-list> and use that instead of the dot-notation one, since that isn't
self-recursive.  Then we get:

<symbol-expression> ::= <symbol>
		    | ( {<symbol-expression>}* )


This too is a useable grammar.

Both of these avoid mutual recursion, and programs based on these
grammars are perfectly reasonable.  I don't care what grammar you
follow, as long as you follow *some* grammar (equivalent to the
grammar we give you, of course).

However, a couple of points in the book's defense here.

1. We need experience with different grammar, even ones that seem complex
at this point, because we'll have actually complex grammars later.
For example, typical languages have grammars for expressions and statements
that are mutually recursive and aren't so easily straightened out.
For example, something like:

    <statement> ::= <varref> := <expression>
               |    if <expression> then <statement> else <statement>
               |    while <expression> do <statement>
               |    <statement> ; <statement>

    <expression> ::= <varref>
                 |  <expression> + <expression>
                 |  begin <statement> <expression> end

It would be hard to disentangle such a grammar in the way we did above;
more to the point, you wouldn't want to, because you want to have
parts of your program that work with statements and expressions.

2. One reason for keeping the s-list and symbol-expression grammars
mutually recursive is that if we want to deal with both types in the same way,
that is convenient when we have the two related procedures.
Admittedly, this is a bit forced for the s-list and symbol-expression
stuff, but as you can see from examples like the above, more realistic cases
have more realistic needs along these lines.

I invite you to try out some of these ideas, and see what you think of
the different s-list and symbol-expression grammars.

	Gary
--
        229 Atanasoff Hall, Department of Computer Science
        Iowa State Univ., Ames, Iowa 50011-1040 USA
        leavens@cs.iastate.edu  phone: +1 515 294-1580 fax: +1 515 294-0258
        URL: http://www.cs.iastate.edu/~leavens/homepage.html