Free grammars software for linux

XML-Grammar-Screenplay is a processor for well-formed plain text representing Screenplays.

This in turn is rendered into a specialized XML format, and that in turn can be converted to HTML or DocBook/XML.

INSTALLATION

To install this module, run the following commands:

perl Build.PL
./Build
./Build test
./Build install

Rats! is an easily extensible parser generator for C-like languages; though currently it only generates parsers in Java. Rats! project has been explicitly designed so that grammars are concise and easily modifiable. To this end, Rats!
- organizes grammars into modules,
- builds on parsing expression grammars instead of context-free grammars and vintegrates lexing with parsing, i.e., is scannerless,
- supports the automatic generation of abstract syntax trees,
- and provides a well-defined interface for extending parsers to recognize context-sensitive languages and formats.
Parsers generated by Rats! memoize intermediate results, which ensures linear time performance in the presence of unlimited lookahead and backtracking. As a result, they are essentially functional (even though they are implemented in an imperative language) and also called "packrat parsers."
Main features:
- Rats! relies on a module system to structure grammars and their extensions. In particular, it relies on modules to group related productions into separate units. Next, module modifications concisely express extensions to other modules and can add, change, or remove individual alternatives in productions. Finally, module parameters are used to compose modules and their extensions with each other.
- Rats! grammars build on parsing expression grammars (PEGs). While PEGs share many constructs with the familiar EBNF notation, a key difference is that they utilize ordered choices instead of the unordered choices used by context-free grammars (CFGs) and other parser generators, such as Yacc or ANTLR. As a result, Rats! grammars avoid ambiguities and support localized changes. Additional flexibility is offered through syntactic predicates, which match expressions but do not consume the input, thus providing unlimited lookahead, and through the integration of lexing with parsing, which greatly simplifies the addition of new tokens to a grammar. PEGs have the additional benefit that they are not only closed under composition (unlike the LR or LL grammars used by Yacc and ANTLR), but also intersection and complement (unlike CFGs in general).
- To eliminate the need for explicit semantic actions, Rats! can automatically generate abstract syntax trees. In particular, it supports productions that return no semantic values (such as those recognizing spaces or comments), string values (such as those recognizing literals or identifiers), and generic tree nodes (potentially all other productions).
- Since some computer-readable formats are inherently context-sensitive and cannot be expressed as PEGs (or CFGs), Rats! supports two techniques for managing parser context or state, thus providing a well-defined interface for extending parsers. First, Rats! provides parser actions to recognize expressions that depend on local context, i.e., expressions that depend on immediately preceding expressions within the same production. An example for such local context is an explicit length preceding as many instances of some expression. Second, Rats! supports a global state object to recognize expressions that depend on possibly global context. State modifications are performed within lightweight transactions, which preserve the basically functional nature of Rats!-generated parsers. An example for a global context is the symbol table used for disambiguating variable and typedef names when parsing C.
Enhancements:
- Release highlights are support for formatting-preserving source refactorings through parse trees, support for parsing and pretty printing Java 5, (an improved abstract syntax tree for Java, and improved support for type checking C and Java ASTs.

Bigtop::Parser is the Parse::RecDescent grammar driven parser for bigtop files.

SYNOPSIS

Make a file like this:
config {
base_dir `/home/username`;
Type1 Backend {}
Type2 Backend {}
Type3 Backend {}
}
app App::Name {
table name { }
controller SomeController {}
}
Then run this command:
bigtop my.bigtop all

This module is really only designed to be used by bigtop. It provides the grammar which understands bigtop files and turns them into syntax trees. It provides various utility functions for bigtop (or similar tools you might write) and for backends.

Reading further is an indication that you are interested in working on Bigtop and not just in using it to serve your needs.

LLg is a recursive descent parser generator.

SYNOPSIS

use LLg;
@tokens = (
ADDOP => [-+],
LEFTP => [(],
RIGHTP => [)],
INTEGER => 0|[1-9][0-9]*,
);
$reader = Lex->new(@tokens);
$ADDOP->debug;

$expr = And->new(($factor, Any->new($ADDOP, $factor)),
sub {
shift(@_);
my $result = shift(@_);
my ($op, $integer);
while ($#_ >= 0) {
($op, $integer) = (shift(@_), shift(@_));
if ($op eq +) {
$result += $integer;
} else {
$result -= $integer;
}
}
$result;
});
$factor = Or->new($INTEGER, $parexp);
$parexp = And->new($LEFTP, $expr, $RIGHTP,
sub { $_[2] });

print STDERR "Type your arithmetic expression: ";
print "Result: ", $expr->next, "n";

Creating parsers by hand is tedious even for simple languages. This activity can be automated by parser-generators - yacc is a well-known example. But using such tools is quite demanding and requires a reasonable knowlege of the principles of syntactic analysis.

LLg is a set of Perl5 packages which allow the generation of recursive descent parsers for context-free grammars.

LLg is provided with the packages Lex and Token which are object-based. The use of these packages presupposes that you know how to write a BNF grammar and that you know (just a little) about programming in Perl.

Specifying the parser does not require any extension to Perl syntax. The specification is carried out entirely in standard Perl, be it definition of tokens, syntactic rules or associated semantic actions. LLg allows the easy specification of translation schemes, that is parsers for which the semantic action is given by actions directly associated with each production.

The packages Token and LLg allow respectively the definition of objects corresponding to terminals (tokens) and non-terminals of the grammar. Lex handles the reading and "eating" of tokens in the input stream.

Before using these packages you need to define a BNF grammar without left recursion (an LL(1) grammar). Given this, making the parser consists in:

1. create a lexical analyser by specifying the terminals,
2. create a parser (syntactic analyser) by creating a LLg object (or, more precisely, one of the packages which inherits from LLg) for each non-terminal.
3. define the semantics by associating an anonymous function with each LLg object.

Take as an example arithmetic expressions having only + and - as operators. In the Camel book we find the following grammar:

expr ::= factor { ADDOP factor }
ADDOP ::= + | -
factor ::= NUMBER | ( expr )

Creating the parser for this language involves defining a lexical analyser and a syntactic analyser.

The lexical analyser is defined thusly:

@tokens = (
ADDOP => [-+],
LEFTP => [(],
RIGHTP => [)],
INTEGER => [1-9][0-9]*,
);
$reader = Lex->new(@tokens);

The argument of the method new() is a list of pairs: the identity of the terminal and the corresponding regular expression. Each such pair leads to the creation of a terminal of type Token.

The package LLg is the base package of a set : And, Any, Do, Hook, Opt, Or. These packages allow the creation of the different types of rules normally found in context-free grammars. We use a prefix notation with the following equivalences.

A | B Or->new($A, $B) symbol A or symbol B


A B And->new($A, $B) symbol A followed by symbol B


{ A } Any->new($A) arbitrary number of A


[ A ] Opt->new($A) zero or one occurrence of A

The rules in our example are given by creating the following objects:

$expr = And->new(($factor, Any->new($ADDOP, $factor));
$factor = Or->new($NUMBER, $parexp);
$parexp = And->new($LEFTP, $expr, $RIGHTP);

The arguments of the method new() are references to LLg or Token objects. (The written order of the rule has no significance, since scalars can be references before they are assigned a value. These references are resolved when each object is used. As the example shows, references can be obtained to the objects returned by a rule.)

The semantics is defined by putting an anonymous function at the end of the list of object references. The anonymous function uses information associated with the objects. This information is transmitted by positional parameters (the array @_). The nth argument designates the result of the nth parameter of the method new(). Information returned by the function is associated with the object and is transmitted by means of positional parameters wherever the object is used. In our example we will have:

$expr = And->new(($factor, Any->new($ADDOP, $factor)),
sub {
shift(@_);
my $result = shift(@_);
my ($op, $integer);
while ($#_ >= 0) {
($op, $integer) = (shift(@_), shift(@_));
if ($op eq +) {
$result += $integer;
} else {
$result -= $integer;
}
}
$result;
});
$factor = Or->new($INTEGER, $parexp);
$parexp = And->new($LEFTP, $expr, $RIGHTP,
sub { $_[2] });

print STDERR "Type your arithmetic expression: ";
print "Result: ", $expr->next, "n";

When an integer is recognised it is returned by the anonymous function associated with the object $factor. This returned information (or, more precisely, synthesised, since it comes from a a terminal and is transmitted to non-terminals) is also available in the anonymous function associated with the object $expr. The information returned by the following object is used to calculate the value of the arithmetical expression.

The analyser is started up by applying the method next() to the axiom of the grammar:

$expr->next;

By default the input for analysis is read from the standard input. The example parser analyses and interprets individual expressions typed in at the terminal. The example calculator.pl delivered with the LLg package shows how to create an input loop allowing reading and interpretation of arbitrary many expressions.
The parser generator can be used for other purposes than the analysis of a character stream. Given that the packages Lex, LLg and Token, it is perfectly possible to define terminals which are objects i.e. instances of a class other than Token. Each new package defining terminals ought at least to have the methods status() and next() - see vonkoch.pl as an example.

Konjugator project is a conjugator for Welsh inflected verbs.
It produces a list of around 200,000 inflected verb forms for almost 4,000 Welsh verbs, along with English glosses and parsing information.
It attempts to conjugate Welsh verbs that are unknown to it, and will give parsing details for random Welsh verb forms if these are known to it.
Main features:
- a spelling checker (for which Konjugator will provide the verb input),
- a grammar checker (the current main focus of work),
- a dictionary,
- and a basic Welsh-English auto-translator.

PerlPoint::Parser Perl module is a PerlPoint Parser.

SYNOPSIS

# load the module:
use PerlPoint::Parser;

# build the parser and run it
# to get intermediate data in @stream
my ($parser)=new PerlPoint::Parser;
$parser->run(
stream => @stream,
files => @files,
);

The PerlPoint format, initially designed by Tom Christiansen, is intended to provide a simple and portable way to generate slides without the need of a proprietary product. Slides can be prepared in a text editor of your choice, generated on any platform where you find perl, and presented by any browser which can render the chosen output format.

To sum it up, PerlPoint Software takes an ASCII text and transforms it into slides written in a certain document description language. This is, by tradition, usually HTML, but you may decide to use another format like XML, SGML, TeX or whatever you want.

Well, this sounds fine, but how to build a translator which transforms ASCII into the output format of your choice? Thats what PerlPoint::Parser is made for. It performs the first translation step by parsing ASCII and transforming it into an intermediate stream format, which can be processed by a subsequently called translator backend. By separating parsing and output generation we get the flexibility to write as many backends as necessary by using the same parser frontend for all translators.

PerlPoint::Parser supports the complete GRAMMAR with exception of certain tags. Tags are supported the most common way: the parser recognizes any tag which is declared by the author of a translator. This way the parser can be used for various flavours of the PerlPoint language without having to be modified. So, if there is a need of a certain new flag, it can quickly be added without any change to PerlPoint::Parser.

The following chapters describe the input format (GRAMMAR) and the generated stream format (STREAM FORMAT). Finally, the class methods are described to show you how to build a parser.

Mail::RFC822::Address is a Perl extension for validating email addresses according to RFC822.

SYNOPSIS

use Mail::RFC822::Address qw(valid validlist);

if (valid("pdw@ex-parrot.com")) {
print "Thats a valid addressn";
}

if (validlist("pdw@ex-parrot.com, other@elsewhere.com")) {
print "Thats a valid list of addressesn";
}

Mail::RFC822::Address validates email addresses against the grammar described in RFC 822 using regular expressions. How to validate a user supplied email address is a FAQ (see perlfaq9): the only sure way to see if a supplied email address is genuine is to send an email to it and see if the user recieves it. The one useful check that can be performed on an address is to check that the email address is syntactically valid. That is what this module does.

This module is functionally equivalent to RFC::RFC822::Address, but uses regular expressions rather than the Parse::RecDescent parser. This means that startup time is greatly reduced making it suitable for use in transient scripts such as CGI scripts.

valid ( address )

Returns true or false to indicate if address is an RFC822 valid address.

validlist ( addresslist )

In scalar context, returns true if the parameter is an RFC822 valid list of addresses.

In list context, returns an empty list on failure (an invalid address was found); otherwise a list whose first element is the number of addresses found and whose remaining elements are the addresses. This is needed to disambiguate failure (invalid) from success with no addresses found, because an empty string is a valid list

Parse::Nibbler is Perl module to parse huge files using grammars written in pure perl.

Create a parser object using the ->new method. This method is provided by the Parse::Nibbler module and should not be overridden.

The main functionality of the Parse::Nibbler module is the Register subroutine. This subroutine is used to define the rules of your grammar. The Register subroutine takes two parameters: A string and a code reference.

The string is the name of the rule (i.e. the name of the subroutine/method)

The code reference is a reference to the code to execute for this rule.

The Register subroutine will take the code reference, wrap it up in another subroutine that acts as a closure, and then installs that code reference as a subroutine with the name matching the given string.

The wrapper code (the closure) is the same for every rule. The wrapper code handles quantifiers, calls the rule, and decides what to do based on the rule passing or failing.
A rule is a code reference with a given string name that have been passed to Register. Here is an example of a rule:
Register ( Name, sub { my $p = shift; $p->AlternateValues( Jim, Scotty, Spock );
}
);

The parser object will always be passed in as the first parameter to your rule. You must pass this into any further rules or any Parse::Nibbler methods.

In the above example, the rule, "Name" is Registered. "Name" calls one of the builtin methods, AlternateValues, defined below. Once a rule is Registered, other rules can call it:
Register ( MedicalDiagnosis, sub { my $p = shift; $p->AlternateValues("Hes", "Shes"); $p->ValueIs("dead"); $p->ValueIs(","); $p->Name; $p->ValueIs("!"); } );

This code registers a rule called "MedicalDiagnosis". It uses some builtin methods, but it also calls the rule just registered, "Name".

Once a user defines a rule, they can use it in other rules by simply calling it as they would call a method.

Rules registered with the Parse::Nibbler module can be called with quantifiers. Quantifiers are passed into the Rule when you call it in your grammar by passing in a string that matches the format described here.

Quantifiers allow you to specify the quantity of rules present. Quantifiers also allow you to specify whether multiple rules have separators.

Quantifiers are specified using the following string format:

{quantifier}

This indicates that there are zero or one Name rules expected: $p->Name({?});
This indicates that there are zero or more Name rules expected: $p->Name({*});
This indicates that there are one or more Name rules expected: $p->Name({+});
This indicates that there are exactly three Name rules expected: $p->Name({3});
This indicates there are 1 to 3 Name rules expected: $p->Name({1:3});
This indicates there are at least 2 Name rules expected: $p->Name({2:);

Separators are specified using the following string format:

/separator/

This indicates 1 or more Name rules, each separated by a comma:

$p->Name({1:}/,/);

It is the job of the Register function to make sure this additional functionality is provided transparently and automagically to you.

If you call a rule with no quantifier and no separator, the rule will assume the quantifier is 1 and there is no separator.

Additional Parse::Nibbler methods are provided to simplify rule definition and to provide smart, automatic error handling, etc. You grammars should only call other rules that you defined, or these methods explained below.

(Note: these methods do not take quantifiers)
############### Method: ValueIs ###############
Parameters: One parameter, required. A string containing the expected value.
Example: $p->ValueIs( stringvalue );
Description:
This method will look at the next lexical and determine if its value matches that of the stringvalue given as a parameter. If it does not match, an exception is raised and the rule fails.
If the values do match, then the parser stores the lexical, and the rule continues.
####################### Method: AlternateValues #######################
Parameters: A list of string parameters, at least two values.
Example: $p-AlternateValues( value1, value2 );
Description:
This method behaves like the ValueIs method, except that it will recieve a list of allowed alternate expected values. The first match that succeeds causes the rule to pass and return.
If no match occurs, then an exception is raised and the rule aborts.
If a match does occur, the parser stores the lexical, and the rule continues.
############## Method: TypeIs ##############
Parameters: One parameter, required. A string containing the expected type.
Description:
This method will look at the next lexical item, and determine if the lexical type matches the type given as a parameter.
Valid type values depend on the Lexer that you use, but possible values may include "Identifier" and "Number", etc.
Use this in a case where your rule requires an identifier type, for example, but it does not care what the name of the identifier is for the rule.
If a match occurs, the parser stores the lexical and the rule continues.
If a match does not occur, an exception is raised, and the rule aborts.
###################### Method: AlternateRules ######################
Parameters: A list of string parameters, at least two.
Example: $p->AlternateRules( Rule1, Rule2 );
Description:
You can describe rule alternation in your rule by calling this method. The method takes a list of strings whose string values match the names of the valid alternate rule names.
In the above example, the McCoy rule is either a declaration of profession or a medical diagnosis. These are two rules that are defined in the same package. The AlternateRules method allows you to define multiple rules that may be valid at the same point in the text.
If a rule in the parameter list succeeds, the AlternateRule method succeeds, and returns immediately.
If no rule succeeds, an exception is thrown, and the rule aborts.
This rule expects either a "DeclareProfession" rule or a "MedicalDiagnosis" rule to be present.
Register ( McCoy, sub { my $p = shift; $p->AlternateRules( DeclareProfession, MedicalDiagnosis ); } );
You can specify quantifiers as part of the alternate rule strings.
$p->AlternateRules( DeclareProfession({+}), MedicalDiagnosis );
The above example indicates that you can have one or more DeclareProfession rules OR ALTERNATELY you can have exactly one MedicalDiagnosis rule.

EXPORT

Register, used to register the rules in your grammar.