Using cycbison:

* Here's a sample grammar for reverse-polish notation.  Note that we
more or less follow exactly the same conventions as in the C version.
You translate it to cyclone code with:

  cycbison -d rpcalc.y

This produces two files rpcalc_tab.cyc and rpcalc_tab.h.  The .h file
is suitable for including within a lexer or some other tool.  The parser
contains all of the tables as well as the parse engine.  It's invoked
by calling yyparse() which in turn calls yylex() expecting that yylex()
produces an integer token and a semantic value in yylval.

The type of yylval is always declared as @tagged union YYSTYPE.
Cycbison will add variants to the union as necessary so that
each semantic value can be represented as a YYSTYPE value.  
So, for instance, if you declare the %type of a production to
be T, then YYSTYPE will have a T variant added to it.  You
can use the %union declaration to give a particular naem to
the variant for a given type.  For instance, if you want to
make all int's be placed in the member Integer, and all doubles
to be placed in the member Double, you could specify:

  %union {
    Integer(int);
    Double(double);
  }

One declares tokens using the %token <id> notation as in bison.

One declares the type of tokens (terminals) and non-terminals
using %type <type> t1 t2 ... tn.  If <type> has not been declared
in the %union section, then Cycbison adds a new variant for
this type to the YYSTYPE declaration.

The grammar rules work just as in bison/yacc.  The biggest difference
is within the actions of the grammar rules.  In particular, $$ refers
to yylval.  Because it's declared to be of type YYSTYPE, anything
that goes into $$ should have this type.  If you use it as an r-value,
then you probably need to switch on it.

$1 $2 and so forth continue to refer to the semantic elements of the rule.
They are translated so as to implicitly "downcast" to the "type" of
the [non-]terminal.

Some new syntax is ^$(e).  This is essentially translated to new
field(e) where field is the field name of the union associated with $$
(i.e., the rule's left-hand-side.)

So for instance, in the grammar below, for the "+" case, we have as the
action:

	exp : exp exp '+' { $$ = ^$($1 + $2); }

The $1 gets the exp value.  Since exp is associated with the foo label
of the union, this means that the semantic value is cast to "int" from
YYSTYPE.  Similarly for $2.  The default semantic value would be there
for the token '+'.  Anyway, because $1 and $2 are automatically cast
to integers, we can add them to produce an integer.  But we can't
just place the result in $$ -- rather, we have to "cast up", hence
the ^$ wrapped around the expression.
---file rpcalc.y--------------------------------------------------------------
%{
#include <core.h> 
#include <stdio.h>
%}

%token NUM 
%type <int> exp NUM line input

%% /* Grammar rules and actions follow */

input:   /*empty*/      { $$ = ^$(3); }
        | input line   { $$ = ^$(4); }
;

line:   '\n'       { $$ = ^$(6); }
        | exp '\n' { printf("RESULT = %d\n",$1);
		     $$ = ^$(5); }
;

exp:    NUM { $$ = ^$($1); }
        | exp exp '+' { $$ = ^$($1 + $2); }
        | exp exp '-' { $$ = ^$($1 - $2); }
        | exp exp '*' { $$ = ^$($1 - $2); }

;
%%
------------------------------------------------------------------------------
