=head1 NAME
 
Parse::Eyapp::eyappintro - An introduction to Parse::Eyapp
 
=head1 SYNOPSIS
 

  # File 'calc.eyp': translates infix expressions to postfix
  # Compile it with:  eyapp -o calc.pl -C Postfix.eyp
  # Execution:        ./calc.pl -c 'a = 2*3+b'
  %token NUM = /([0-9]+(?:\.[0-9]+)?)/
  %token VAR = /([A-Za-z][A-Za-z0-9_]*)/

  %right  '='
  %left   '-' '+'
  %left   '*' '/'
  %left   NEG

  %defaultaction { "$left $right $op"; }

  %%
  line: $exp  { print "$exp\n" }
  ;

  exp:        $NUM  { $NUM }            
          |   $VAR  { $VAR }            
          |   VAR.left '='.op exp.right         
          |   exp.left '+'.op exp.right         
          |   exp.left '-'.op exp.right        
          |   exp.left '*'.op exp.right       
          |   exp.left '/'.op exp.right      
          |   '-' $exp %prec NEG { "$exp NEG" }
          |   '(' $exp ')' { $exp }      
  ;

  %%



=head1 INTRODUCTION TO PARSING WITH Parse::Eyapp

=head2 Introduction

Parsing is the activity of producing a syntax tree
from an input stream. The program example in the synopsis 
section shows an example of a translation scheme. 
It translates infix arithmetic expressions like 

   a = 2 * 3 + 4 * b

into postfix expressions like 

   a 2 3 * 4 b * + =

The program contains a context free eyapp grammar defining the language 
of arithmetic infix expressions. A context free grammar
is a mathematical device to define languages. To better see the grammar
for the example above we have to eliminate the semantic 
actions (We call semantic actions to the sections delimited by curly brackets
containing Perl code).
This can be done calling C<eyapp> with options C<-vc>:

  $ eyapp -vc Postfix.eyp 
  %token NUM =/([0-9]+(?:\.[0-9]+)?)/ 
  %token VAR =/([A-Za-z][A-Za-z0-9_]*)/ 
  %right '=' 
  %left '-' '+' 
  %left '*' '/' 
  %left NEG 

  %%

  line:
        exp 
  ;
  exp:
        NUM
      | VAR
      | VAR '=' exp
      | exp '+' exp
      | exp '-' exp
      | exp '*' exp
      | exp '/' exp
      | '-' exp %prec NEG
      | '(' exp ')'  
  ;

  %%


A grammar generates a language. A grammar is defined by a set of production rules. A production rule
has two components: a left hand side which is a I<syntactic variable> or I<non terminal> and a right hand side
which is a phrase made of syntactic variables and terminals. The left hand side (I<lhs>) and the right
hand side (I<rhs>) are usually separated by an arrow like in:

                                    exp -> VAR = exp

A note: when you see a production rule like:

                        line: exp <+ ';'>

is not really a production rule but an abbreviation for two productions. It stands for:

                        line : exp
                             | line ';' exp
                        ;


A I<terminal> or I<token> never appears on the left hand side of a production rule.

=head2 Ambiguity

The phrases of the language are those obtained 
successively applying the production rules of the grammar until no more rules can be applied.
The successive substitutions must start from the C<start> symbol of the grammar (C<line> in
the example). Such legal
sequence of substitutions is known as a I<derivation>. The following is an example of a
legal derivation (the big arrow C<=E<gt>> is read I<derives>):

  line => exp => VAR = exp => VAR = exp + exp => VAR = exp + NUM => VAR = VAR + NUM

thus the phrase C<VAR = VAR + NUM> belongs to the language generated by the former grammar.
A derivation like this can be seen as a tree. For instance, the former derivation is equivalent (has 
the same information) than the following tree:

                             +----+
                             |line|
                             +----+
                                |
                              +---+
                              |exp|
                              +---+
                    .-----.-----^-----.
                  +---+ +---+        +---+
                  |VAR| | = |        |exp|
                  +---+ +---+        +---+
                                 .-----+-----.
                               +---+ +---+ +---+
                               |exp| | + | |exp|
                               +---+ +---+ +---+
                                 |           |
                               +---+       +---+
                               |VAR|       |NUM|
                               +---+       +---+

which can be written more succinctly:

                        line(exp(VAR, '=', exp(exp(VAR), '+',  exp(NUM))))

or even more briefly:

                                      VAR = (VAR + NUM)

Such a tree is called a I<syntax tree> for the input C<VAR = VAR + NUM>.
A grammar is said to be I<ambiguous> if there are phrases in the generated language that have
more than one syntax tree. The grammar in the synopsis example is ambiguous. Here is an alternative
tree for the same phrase C<VAR = VAR + NUM>:

                                    +----+
                                    |line|
                                    +----+
                                       |
                                     +---+
                                     |exp|
                                     +---+
                            .----------^-----.-----.
                          +---+            +---+  +---+
                          |exp|            | + |  |exp|
                          +---+            +---+  +---+
                      .-----+-----.                 |
                    +---+ +---+ +---+             +---+
                    |VAR| | = | |exp|             |NUM|
                    +---+ +---+ +---+             +---+
                                  |
                                +---+
                                |VAR|
                                +---+

or

                        line(exp(exp(VAR, '=', exp(VAR)), '+', exp(NUM)))

or

                                     (VAR = VAR) + NUM

=head2 Semantic Actions and Attributes

C<Parse::Eyapp> analyzes your grammar and produce a LALR parser.
Actually the SYNOPSIS example is more than a context free grammar: 
is a I<translation scheme>. A I<translation scheme> 
scheme is a context free grammar where the right hand sides of the productions 
have been augmented with semantic actions (i.e. with chunks of Perl code):

                                A -> alpha { action(@_) } beta

The analyzer generated by Eyapp executes C<{ action(@_) }> after all the semantic actions
associated with C<alpha> have been executed and before the execution of any of the semantic 
actions associated with C<beta>. 

In a translation scheme each symbol occurrence has an I<associated attribute>.
The embedded actions modify the attributes associated with the symbols of the grammar:

                        A -> alpha { action(@_) } beta

I<Each symbol on the right hand side
of a production rule has an associated scalar attribute>. 
In C<eyapp> the attributes of the symbols
to the left of C<action> are passed as arguments to C<action> (in the example, those of C<alpha>). 
These arguments are preceded by a reference to the syntax analyzer object.
Therefore, you can access to the attributes associated with the first, second, etc. symbols in the right
hand side using the notation:

               $_[1], $_[2], ...

However it is better to refer to the attributes by names. This is the purpose of the dot
and dollar notations as in:

  exp:        $NUM  { $NUM }            
          |   $VAR  { $VAR }            
          |   VAR.left '='.op exp.right         
          |   exp.left '+'.op exp.right         
          |   exp.left '-'.op exp.right        
          |   exp.left '*'.op exp.right       
          |   exp.left '/'.op exp.right      
          |   '-' $exp %prec NEG { "$exp NEG" }
          |   '(' $exp ')' { $exp }      
  ;

By prefixing the symbol C<NUM> by a C<$> we can refer to the associated attribute inside the semantic action 
as C<$NUM>:

  exp:        $NUM  { $NUM }            

By postfixing the two appearances of C<expr> with C<.left> and C<.right> and the appearance of
C<'+'> with C<.op> we can refer to the associates attributes as C<$left>, C<$right> and C<$op>
instead of C<$_[1]>, C<$_[3]> and C<$_[2]>:

  %defaultaction { "$left $right $op"; }

There is no way inside an ordinary C<eyapp> program for an intermediate C<action> to 
access the attributes of the symbols
on its right, i.e. those associated with the symbols of C<beta>. This restriction is lifted 
if you  use the C<%metatree> directive to build a I<full translation scheme>. 
See 
L<Parse::Eyapp::translationschemestut>
to know more about full translation schemes.

Actions on the 
right hand side counts as symbols and so they can be referenced by its positional argument
in later actions in the same production rule. For intermediate actions, the value returned by the C<action> is 
the attribute associated with such action. For an action at the end of the rule:

                        A -> alpha { lastaction(@_) } 

the returned value constitutes the attribute of the left hand side of the rule (the
attribute of C<A> in this case). The action at the end of the right hand side is 
called the I<action associated with the production rule>. When no explicit action
has been associated with a production rule the I<default action> applies. In C<Parse::Eyapp>
the programmer can define what is the default action through the C<%defaultaction> directive: 


                        %defaultaction { "$left $right $op"; }

Actually, intermediate actions are implemented via a trick. When C<eyapp> sees
an intermediate action like:

                        A -> alpha { action(@_) } beta

it creates a new auxiliary syntactic variable C<Temp>:

                      Temp -> /* empty */ { action(@_) }

=head2 Solving Ambiguities via Precedence and Associativity Declarations

Notice that ambiguous grammars produce ambiguous translation schemes: 
since a phrase may have two syntactic
trees it will be more than one tree-traversing and consequently more than one 
way to execute the embedded semantic actions. Certainly different execution
orders will usually produce different results. Thus, syntactic ambiguities translate
onto semantic ambiguities. That is why it is so important to resolve all the 
ambiguities and conflicts that may arise in our grammars. This is the function 
of the C<%left> and C<%right> declarations on the header section:

      %right  '='     # Lowest precedence
      %left   '-' '+' # + and - have more precedence than = Disambiguate a-b-c as (a-b)-c
      %left   '*' '/' # * and / have more precedence than + Disambiguate a/b/c as (a/b)/c
      %left   NEG     # Disambiguate -a-b as (-a)-b and not as -(a-b)

Priority can be assigned to tokens by using the C<%left> and C<%right> declarations. I<Tokens in
lines below have more precedence than tokens in line above>. 
The idea  behind this notation is this: 
I<Any ambiguity can be seen as a parenthesizing problem>. You can parenthesize left (in the jargon this
is called I<reduce>) or parenthesize right (in the jargon, I<shift>).
Recall the main points of yacc-like parsers related to priorities:

=over 2

=item * The directives

            %left
            %right
            %nonassoc

can be used in the head section to declare the priority of a token

=item * The later the declaration line the higher the priority

=item * Tokens in the same line have the same priority. Ties will be solved
using the token associativity (whether they were declared C<%left> or C<%right>)


=item * The I<precedence of a production rule (right hand side) is the precedence
of the last token in the right hand side>

=item * If the parser emits a warning announcing a shift-reduce conflict or a reduce-reduce
conflict in your grammar, it likely means that your grammar is ambiguous or not LALR.
In such case, recompile the grammar with C<eyapp -v> and carefully study the C<.output> file generated.
I<Detect which token and which rules are involved in the conflict>.

=item * In a shift-reduce conflict the default action is to shift (i.e. associate right). This action can be changed
if the production and the token involved have explicit priorities

=item * Most of the time the presence of a reduce-reduce conflict 
means that your grammar is ambiguous. Rewrite your grammar. Alternatively, use the C<%conflict> and C<%PREC> directives
(see example C<debuggintut/pascalenumeratedvsrangesolvedviadyn.eyp>). 
The default action is to reduce by the first production.

=item * If the precedence of the production rule is higher the shift-reduce conflict is solved 
in favor of the reduction (i.e. associate left)

=item * If the precedence of the token is higher the shift-reduce conflict is solved 
in favor of the shift (i.e. associate right).

=item * If the precedence of the token is the same than the precedence of the rule, and is left 
the shift-reduce conflict is solved in favor of the reduction (i.e. associate left)

=item * If the precedence of the token is the same than the precedence of the rule, and is right 
the shift-reduce conflict is solved in favor of the shift

=item * If the precedence of the token is the same than the precedence of the rule, and is nonassoc 
the presence of a shift-reduce conflict means an error.
This is used to describe operators, like the operator C<.LT.> in FORTRAN, 
that may not associate with themselves. That is, because

                             A .LT. B .LT. C

is invalid in FORTRAN, C<.LT.> would be described with the keyword C<%nonassoc> in eyapp. 

=item * The default precedence of a production can be changed using the C<%prec TOKEN> directive.
Now the rule has the precedence and I<associativity> of the specified C<TOKEN>.

=back

=head2 Examples

=over 2

=item 

By giving token C<'+'> more precedence than token C<'='> we solve the ambiguity in
C<VAR = VAR + NUM> in favor of C< VAR = (VAR + NUM)>. The conflict occurs between the productions

                            exp -> exp . '+' exp 
                            exp -> VAR '=' exp .

Where the dot means: 

I<If I have seen> C<VAR '=' exp> 
I<and I am in the presence of a token> C<'+'> I<I can associate left, i.e. reduce> 
C<VAR '=' exp> I<to> C<exp> 
I<or to associate right,> 
I<that is, to shift to the right to reduce> C<exp '+' exp> I<to> C<exp> I<later>.

=item 

How it works when two tokens are declared in the same line?
Consider the phrase C<NUM - NUM - NUM>. It will be interpreted
as C<(NUM - NUM) - NUM> if the token C<'-'> is declared C<%left '-'> and 
will be interpreted as C<NUM - (NUM - NUM)>  if the token C<'-'> is declared C<%right '-'>.
By saying C<'-'> is left
we are saying we  prefer between the two trees in dispute the one
that deepens to the left:

                                       +---+
                                       |exp|
                                       +---+
                                .--------^--.-----.
                              +---+       +---+ +---+
                              |exp|       | - | |exp|
                              +---+       +---+ +---+
                          .-----+-----.           |
                        +---+ +---+ +---+       +---+
                        |exp| | - | |exp|       |NUM|
                        +---+ +---+ +---+       +---+
                          |           |
                        +---+       +---+
                        |NUM|       |NUM|
                        +---+       +---+

By saying C<'-'> is right we are saying we  prefer between the two trees in dispute the one
that deepens to the right:

                                        +---+
                                        |exp|
                                        +---+
                              .-----.-----^-----.
                            +---+ +---+       +---+
                            |exp| |MIN|       |exp|
                            +---+ +---+       +---+
                              |           .-----+-----.
                            +---+       +---+ +---+ +---+
                            |NUM|       |exp| |MIN| |exp|
                            +---+       +---+ +---+ +---+
                                           |           |
                                         +---+       +---+
                                         |NUM|       |NUM|
                                         +---+       +---+


Since I<priority means earlier evaluation>
and the evaluation by L<eyapp> of semantic actions is bottom up, I<the deeper the associated subtree the higher
the priority>.

=item 

Consider now the phrase C<-NUM-NUM>. There are two interpretations:
one as C<-(NUM-NUM)> and the other as C<(-NUM)-NUM>. The conflict occurs between the productions

                            exp -> exp . '-' exp 
                            exp -> '-' exp.

Both productions have the precedence of the token C<'-'>. But we prefer the interpretation
C<(-NUM)-NUM> to win. We do that by explicitly changing the precedence associated with
the unary minus production via the C<%prec> directive.
                      
=back

=head2 Lexical Analysis

Parsers created by C<eyapp> do not deal directly with the input. Instead they expect the input
to be processed by a I<lexical analyzer>. The lexical analyzer parses the input and produces
the next token. A I<token> is a pair. The first component is the name of the token (like C<NUM>
or C<VAR>) and the second is its attribute (i.e. the information associated with the token, like 
that the value is C<4> for a C<NUM> or the identifier is C<temperature> for a
C<VAR>). Tokens are usually defined using regular expressions. Thus the token 
C<NUM> is characterized by C</[0-9]+(?:\.[0-9]+)?/> and the token
C<VAR> by C</[A-Za-z][A-Za-z0-9_]*/>. The L<eyapp> compiler 
automatically generates a lexical analyzer from
your token definitions. The tokens C<NUM> and C<VAR> were defined using the C<%token> directives:

  %token NUM = /([0-9]+(?:\.[0-9]+)?)/
  %token VAR = /([A-Za-z][A-Za-z0-9_]*)/

The order in which the tokens are defined is important. The input will be matched 
against the regular expression for C<NUM> before the regular expression for C<VAR>
is tried, and all the literal tokens that appear between quotes inside the body of the grammar,
like C<'+'> or C<'->, are tried before any explicitly defined token.

You can, alternatively, define the lexical analyzer explicitly. There are many ways to do it.
Here is an example of a 
definition of a lexical analyzer using the C<%lexer> directive:

  %lexer  {
    m{\G[ \t]*}gc;
    m{\G(\n)+}gc                    and $self->tokenline($1 =~ tr/\n//);
    m{\G([0-9]+(?:\.[0-9]+)?)}gc    and return ('NUM',   $1);
    m{\G([A-Za-z_][A-Za-z0-9_]*)}gc and return ('VAR',   $1);
    m{\G(.)}gc                      and return ($1,      $1);
  }

The C<%lexer> directive is followed by the code defining the lexical analyzer.
When called, the variable C<$_> is an alias of the input. 
The input can also be set and accessed via the C<input> method of the C<$parser> object. 

To catch the next pattern we use the anchor C<\G>.
The C<\G> anchor matches at the point where the previous C</g> match left off. 
Normally, when a scalar C<m{}g> match fails, the match position is reset and
C<\G> will start matching at the beginning of the string.
The C<c> option causes the match position to be retained following an unsuccessful match.
The couple C<('',undef)> which signals the end of the input is automatically inserted by 
C<eyapp>.

By default, the lexers generated by C<eyapp> emit the end-of-input token C<('', undef)>
when the end of the current string is reached. A I<incremental lexer> differs from these behavior:
when the end is reached it reads more input from the current file, which was set by
           
                 $parser->YYInputFile

See the following variant of the synopsis example:

  ~/LEyapp/examples/eyappintro$ cat InputFromStream.eyp 
  %whites /([ \t]+)/
  %token NUM = /([0-9]+(?:\.[0-9]+)?)/
  %token VAR = /([A-Za-z][A-Za-z0-9_]*)/

  %right '='
  %left   '-' '+'
  %left   '*' '/'
  %left   NEG

  %defaultaction { "$_[1] $_[3] $_[2]" }

  # example of incremental lexer
  %incremental lexer  'Write an arithmetic expression: '

  %%
  input:                  {}
          |   input line  {}
  ;

  line:     '\n'       {}
          | exp '\n'   { print "$_[1]\n" } 
          | error '\n'   {}
  ;

  exp:        NUM                { $_[1] }
          |   VAR                { $_[1] }
          |   VAR '=' exp         
          |   exp '+' exp         
          |   exp '-' exp        
          |   exp '*' exp       
          |   exp '/' exp      
          |   '-' exp %prec NEG  { "$_[2] NEG" }
          |   '(' exp ')'        { $_[2] } 
  ;

  %%

Now, after the grammar is compiled

  ~/LEyapp/examples/eyappintro$ eyapp -C InputFromStream.eyp 

When the generated modulino is executed, each time the end of the input string is reached, it asks for more
input until we press the end-of-file (C<^D> in Unix) key:

  ~/LEyapp/examples/eyappintro$ ./InputFromStream.pm -noslurp
  Write an arithmetic expression: a=2+3*b
  a 2 3 b * + =
  Write an arithmetic expression: a=-b*2
  a b NEG 2 * =
  Write an arithmetic expression: ^D
  ~/LEyapp/examples/eyappintro$ 

=head2 The C<main> and C<error> subroutines

If you compile your grammar with option C<-C>, C<eyapp> will insert 
a line like this as the first line of the generated C<.pm> file:

                #!/usr/bin/perl

It will also append a line like this as the last line of the C<.pm> file:

          unless (caller) { exit !__PACKAGE__->main(''); }

This allows the alternative use of the module as a script.
Unless a C<main> subroutine was defined, the one provided
by L<Parse::Eyapp::Driver> will be called. It also provides
a default subroutine for the handling of error messages.

The default main accepts a few arguments from the command line.
Here are some:

=over 2

=item * C<-f filename> input from C<filename>

=item * C<-c 'string'> input from C<'string'>

=item * C<-noslurp> when input is from C<STDIN> don't wait for end of file

=back


=head1 SEE ALSO

=over

=item * The project home is at L<http://code.google.com/p/parse-eyapp/>.
Use a subversion client to anonymously check out the latest project source code:

   svn checkout http://parse-eyapp.googlecode.com/svn/trunk/ parse-eyapp-read-only

=item * The tutorial I<Parsing Strings and Trees with> C<Parse::Eyapp>
(An Introduction to Compiler Construction in seven pages) in
L<http://nereida.deioc.ull.es/~pl/eyapsimple/> 

=item * 
L<Parse::Eyapp>, 
L<Parse::Eyapp::eyapplanguageref>, 
L<Parse::Eyapp::debuggingtut>,
L<Parse::Eyapp::defaultactionsintro>,
L<Parse::Eyapp::translationschemestut>,
L<Parse::Eyapp::Driver>,
L<Parse::Eyapp::Node>,
L<Parse::Eyapp::YATW>,
L<Parse::Eyapp::Treeregexp>,
L<Parse::Eyapp::Scope>,
L<Parse::Eyapp::Base>,
L<Parse::Eyapp::datagenerationtut>


=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/languageintro.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/debuggingtut.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/eyapplanguageref.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/Treeregexp.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/Node.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/YATW.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/Eyapp.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/Base.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/translationschemestut.pdf> 

=item * The pdf file in L<http://nereida.deioc.ull.es/~pl/perlexamples/treematchingtut.pdf> 

=item *
perldoc L<eyapp>, 

=item *
perldoc L<treereg>,

=item *
perldoc L<vgg>,

=item * The Syntax Highlight file for vim at L<http://www.vim.org/scripts/script.php?script_id=2453>
and L<http://nereida.deioc.ull.es/~vim/>

=item * I<Analisis Lexico y Sintactico>, (Notes for a course in compiler 
construction) by  Casiano Rodriguez-Leon. 
Available at  L<http://nereida.deioc.ull.es/~pl/perlexamples/>
Is the more complete and reliable source for Parse::Eyapp. However is in Spanish.

=item *
L<Parse::Yapp>,

=item *
Man pages of yacc(1) and
bison(1),
L<http://www.delorie.com/gnu/docs/bison/bison.html>

=item *
L<Language::AttributeGrammar>

=item *
L<Parse::RecDescent>.

=item *
L<HOP::Parser>

=item *
L<HOP::Lexer>

=item * ocamlyacc tutorial at 
L<http://plus.kaist.ac.kr/~shoh/ocaml/ocamllex-ocamlyacc/ocamlyacc-tutorial/ocamlyacc-tutorial.html>

=back

=head1 REFERENCES

=over

=item *
The classic Dragon's book I<Compilers: Principles, Techniques, and Tools> 
by Alfred V. Aho, Ravi Sethi and
Jeffrey D. Ullman (Addison-Wesley 1986)

=item *
I<CS2121: The Implementation and Power of Programming Languages>
(See L<http://www.cs.man.ac.uk/~pjj>, L<http://www.cs.man.ac.uk/~pjj/complang/g2lr.html> 
and L<http://www.cs.man.ac.uk/~pjj/cs2121/ho/ho.html>) by 
Pete Jinks

=back


=head1 CONTRIBUTORS

=over 2

=item * Hal Finkel L<http://www.halssoftware.com/> 

=item * G. Williams L<http://kasei.us/>

=item * Thomas L. Shinnick L<http://search.cpan.org/~tshinnic/>

=item * Frank Leray

=back

=head1 AUTHOR
 
Casiano Rodriguez-Leon (casiano@ull.es)

=head1 ACKNOWLEDGMENTS

This work has been supported by CEE (FEDER) and the Spanish Ministry of
I<Educacion y Ciencia> through I<Plan Nacional I+D+I> number TIN2005-08818-C04-04
(ULL::OPLINK project L<http://www.oplink.ull.es/>). 
Support from Gobierno de Canarias was through GC02210601
(I<Grupos Consolidados>).
The University of La Laguna has also supported my work in many ways
and for many years.

A large percentage of  code is verbatim taken from L<Parse::Yapp> 1.05.
The author of L<Parse::Yapp> is Francois Desarmenien.
 
I wish to thank Francois Desarmenien for his L<Parse::Yapp> module, 
to my students at La Laguna and to the Perl Community. Thanks to 
the people who have contributed to improve the module (see L<Parse::Eyapp/CONTRIBUTORS>).
Thanks to Larry Wall for giving us Perl.
Special thanks to Juana.

=head1 LICENCE AND COPYRIGHT
 
Copyright (c) 2006-2008 Casiano Rodriguez-Leon (casiano@ull.es). All rights reserved.

Parse::Yapp copyright is of Francois Desarmenien, all rights reserved. 1998-2001
 
These modules are free software; you can redistribute it and/or
modify it under the same terms as Perl itself. See L<perlartistic>.
 
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 



