Introduction

On Monday, we talked about table-driven top down parsing and how to build parse tables in this situation.
I said we were going to skip doing bottom up parsing in detail.
If you recall, roughly the idea of bottom up parsing, is as we read tokens, we push them onto the stack, when we see the right hand side of a rule at the top of the stack, we pop the elements from the stack, and replace them with the left hand side of a rule.
You might say, "Hey, we aren't only allowed to peek at the top element of a stack?" How can we check if the right hand side of a rule is really at the top of the stack?
To do this we build a finite automaton called the Characteristic Finite-State Machine for the grammar.
For our example grammar for the simple calculator of last day, the start state of this machine might look like:
The whole thing above represents the name of a state, its members are called items. The dots tell us how far along we are currently in parsing each of the rules.
As we get tokens, we switch to a new state, appropriately advancing the dots of the relevant items. When a dot reaches the end of an item, we can then pop the elements of those tokens from the stack and do a reduce. Then we move the dot back to the start of the item.
For example, if the next token was read, the new state would have stmt `->` `circ` read id replaced with stmt `->` read `circ` id.
Usually, an LR parser maintains two tables a GOTO table which says reading X symbol what state to go to next, and an ACTION table saying whether to shift or reduce, and if reduce what to reduce.
Precisely, which items are needed in a state is determined by the particular kind of LR parsing we are doing. For example, if we are doing LR(0) parsing, given some symbol `S` we just read, the next state's itemset is initialized to empty, and we cycle over all results `N-> alpha circ S\beta` in the current state and add `N-> alpha S circ\beta` to the next state, finally taking the epsilon derivation closure of the result.
Although, we are not going to say much more about bottom up parsing, we did show two command line tools last day: lex - for writing lexer's and yacc - for writing bottom up parser.
I'd like to begin today by quickly flipping through the slides of last day on this, before continuing our discussion on yacc.

Yacc $ variables

Yacc refers to parts of a rule using variables which begin with a dollar sign:

expression : expression '+' expression {$$ = $1 + $3;}
        | expression '-' expression {$$ = $1 - $3;}
	    | NUMBER {$$ =$1;}
        ;

$$ refers to the left hand side of the rule value. $n refers to the nth item on the right hand side.

Typing Tokens

Lex uses a few built-in global variables when it scans its input: yytext, yylval.
The first is a char pointer to the string matching the current token. The second is used to store the value of the $ variable for the given token returned.
yylval has type YYSTYPE which is a union that you can set up in your grammar.

More on Typed Tokens

To set up YYSTYPE in your grammar (will appear in y.tab.h file after yacc'ing):

%{
//stuff
%}
%union {
      double dval; // in this case we have two possibilities
      int ival; // could have more. In real world possibilities
                   // would include a struct for a syntax tree.
}
%token <ival> INTEGER
%token <dval> DOUBLE
%type <dval> expression /*notice can say type of nonterminal */

Typed Tokens and the Lexer

The lexer may then have rules like:

	[0-9]+ {yylval.ival = atoi(yytext); return INTEGER;}

So if you had a rule in your grammar like:

integer_expr : INTEGER {$$ = (double)$1;}
//$1 would have been an int

Typically, you use the typing mechanism so that you can build up a syntax tree for the input as you are parsing it.

Error Handling in Your Grammar

If Yacc encounters an error while parsing, it will call the function yyerror to handle this error.

If you like, you can rewrite yyerror to do whatever you want:

int yyerror( char *s)
{
     fprintf(stderr, "You caused the error: %s , bozo.\n", s);
     return 1;
}

In-Class Exercise

Modify the lexer for word counting so that it counts occurrences of 'a' or 'the' only.
Look at the first compile lines after running lex on your program.
Please post these lines and your code to the Sep 22 In-Class Exercise Thread.

Names, Scopes, and Binding

We want to write in programming languages that are relatively machine independent - for portability, and which are relatively easy as humans to understand and program in.
Abstraction of components of the underlying hardware lets us do this.
For the discussion today, we are interested in the abstraction of names of things.
In most programming languages names are usually identifiers (alphanumeric tokens) that allow us to refer to variables, constants, operations, types, and so on without having to refer to low level concepts like addresses.
They are a kind of abstraction in that they allow us to associate a name with a potential complicated program fragment.
Other kinds of abstractions which we will discuss later are control abstractions such as subroutine which allow the programmer to hide code behind a simple interface, and data abstractions such as classes, which allow us to hide data representation behind a simple set of allowed operations.
For our discussion of names, we will look at when and for how long a name is bound to its value (binding time and scope).

Binding Time

A binding is an association between two things, a name and thing it names.
Binding time refers to the time at which a binding is created.
Some example possible binding times are:
- Language design time names of keywords in the language like void, char, switch, if, else, etc were bound at language design time
- Language implementation time number of bits for an int, implementation of floating point, etc might not be in the language spec, but decided when a particular interpreter or compiler is written.
- Program writing time programmers choose the names for algorithms, data structures, etc.
- Compile time The compiler chooses the mapping from high level constructs to machine code.
- Link time The linker chooses the overall layout of the compiled modules chooses which version of linked libraries to include, and builds the map from names in one module and another.
- Load time - when the program is read into ram by OS. The program needs to read into physical address, and the virtual addresses of the machine code need to be mapped with these physical addresses.
- Run time these include bindings that might occur anytime from when the program starts executing to when it terminates.

Object Lifetime and Storage Management

It is important to distinguish between names and the objects to which they refer, and to identify several key events:
- Creation and destruction of objects
- Creation and destruction of bindings
- Deactivation and reactivation of bindings that may be temporarily unusable
- References to variables, subroutines, types, and so on, all of which use bindings
The period between the creation and the destruction of name-to-object binding is called the binding's lifetime.
The period between the creation and the destruction of an object is called the object's lifetime.
These two lifetimes might not coincide for example if you have a variable reference to an object which is freed, the variable might still exists until the subroutine it was defined in returns. In this case, we have a so-called dangling reference.

Storage Allocation

Object lifetimes generally correspond to one of three principal storage allocation mechanisms:
1. Static objects are given an absolute address that is retained throughout the program's execution.
2. Stack objects are allocated and deallocated in last-in, first--ut order, usually in conjunction with subroutine calls and returns.
3. Heap objects may be allocated and deallocated at arbitrary times. They require a more general (and expensive) storage management algorithm.
Next day, we will consider each of these in detail.

Finish Yacc, Names, Scope, and Binding

Outline