Free antlr software for linux

ANTLR, ANother Tool for Language Recognition, (formerly PCCTS) is a language tool that provides a framework for constructing recognizers, compilers, and translators from grammatical descriptions containing Java, C#, C++, or Python actions.
ANTLR provides excellent support for tree construction, tree walking, and translation. There are currently about 5,000 ANTLR source downloads a month.
Enhancements:
Java CHANGES
- moved consume(); consumeUntil(...) to recover() method you can override in parsers only. New method signature: public void recover(BitSet tokenSet) throws TokenStreamException;
- CommonASTWithHiddenTokens fixed tree builders copy hidden tokens
- ASTFactory; added overloaded method public void setASTNodeClass(Class c);
- default charVocabulary is 0..127 for ASCII range. ~n, for example, gave really wacky results since charVocabulary had no defined range.
- BaseAST.equals() didnt work when node text was null.
- LLkParser.consume now throws TokenStreamException as Parser.consume does.
C++ changes:
- Added TokenStreamRewriteEngine C++ port + example.
- Fixes for sign extension problems that sneaked in 2.7.4.
- Fixes for some quoting bugs in C++ codegeneration.
- Fixes for some wrong extensions in generated docbook and HTML files (for -html/-docbook commandline options).
- Made codegenerator more unicode friendly.
- Tweaks for preliminary UTF8 support. Includes an example that is capable of parsing UTF8 input (more proof of concept than what is to be). (Using a custom InputBuffer and CharScanner). *Feedback on this is appreciated.*
- Fixed codegeneration bug (a..z!) would trigger generation of invalid C++ code.
- Added missing warning for redefinition of AST types for nodes. (Thanks to Sergey Bogdanov)
- Bugfix for AST factory initialization code.
- Fixed default argument mangling for generated rule methods.
- Fixed sign extension problem in error messages in support lib (triggered by MSVC)
- Fixed type generated for saveIndex and _begin variables. Thanks to Brad Schick for the patch.
- getFilename/Line/Column methods added to TokenStreamRecognitionException (thanks to Heinz Beckers)
- Added lexer states to the flex lexer example. It now seems to parse the same set of java as the other antlr java parsers.
- Small tweaks to include files.
- Doc tweaks.
- Revised configure/makefiles by Wolfgang Haefelinger.
C# Changes
Changes for C# support (by Anthony Oguntimehin, Kunle Odutola & Micheal Jordan):
- Factored out IToken and IHiddenStreamToken interfaces.
- ASTPair now supports a protocol for reusing instances. Generated C# code creates far fewer ASTPair instances.
- The values of LA(1) and LA(2) are now cached in lexers
- ASTArray creation/usage replaced with C# variable length parameter lists. ASTArray remains for backwards compatibility only.
- Several bugfixes in antlr.debug to better support ParseView-style tools [Suggested by Eric Taucher.]
- Updated the C# code generator to generate code that uses use cached LA(x) values, reuses ASTPair instances, and uses the new IToken and IHiddenStreamToken interfaces
- Re-organised the ANTLR runtime library for the .NET platform. Library is now packages as two assemblies:
- antlr.runtime.dll - required, core library types and functionality
- antlr.astframe.dll - optional, types and functionality for displaying astframes
- The upshot of all this is that projects that dont need the ASTFrame functionality arent forced to load the System.Drawing and System.Windows.Forms assemblies that it depends on.
- C# VS.NET solution and project files & names have been updated to 2.7.5. Also new project file for the astframe assembly.
- Updated the NAnt build file(s) to support building the new two-assembly runtime.
- Incorporated latest fixes for the java grammar into the C# java example project
- Updated runtime documentation to accomodate the new two-assembly C# runtime.

CleanSheets is a spreadsheet application for the Java platform.

It features a formula language that closely resembles that of Microsoft Excel, and extensions for aiding end-user programmers in developing correct spreadsheets.

The application is written in Java, and relies on ANTLR for generating the formula compiler and the JFC/Swing JTable component for spreadsheet visualization.

Config Maker is a tool to automatically create C++ classes that parse configuration files.

Only a few lines of text that describe the possible entries in the configuration file are needed, and the complete class will be generated ready for use.

Basic usage

The input files for Config Maker have a very simple structure (in ANTLR/grep like notation):

objectname (configentry)+
Each configentry looks like this
type entryname defaultvalue (comment)?

type

Type of the entry, can be int, double, string or bool. If the basic type is followed by any number, the corresponding c++object variable will be of type vector < basic type > The number is the initial number of elements that are allocated for the vector, but the actual configuration file can contain more components. These are added using the push_back method.

If there are less elements specified in the configuration file, the object variable will still contain the number of elements specified here. No warning will be issued.
configentry

Name of the entry and corresponding variable. Has to be at least two characters long and can contain characters and numbers. Case insensitive.

defaultvalue

Default value for the entry. This is optional.

comment

Each comment starts with // and is completely ignored

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.

Obol is part of a project to investigate properties of security protocols, what they are, how they behave, how they interact, how to deal with them. The Obol language grew out of a desire to escape the distractions of low-level implementation efforts, and the need to experiment and express security protocols as independent programs, closer to the level on which security protocols are analysed.
Whats it all about?
Obol is a specialized high-level programming language for security protocols. The idea is to program closer to the abstractions used to describe and analyze security protocols, and leave all the nasty details to the runtime. The runtime will then handle "mundane" issues such as message representation, communication, cryptographic transformations and so on.
Whats the point of that?
By focusing on the security aspects of the protocol being implemented, one avoid the typical entanglement of security protocol code, low-level cryptographic functions, and application logic. Obol keeps these three aspects separate, resulting in a clean, highly modular and very flexible security protocol framework.
Think of it as trying to do for security protocols what SQL did for databases.
Whats it implemented in?
The most mature (and actively developed) runtime version is implemented in Java, using ANTLR for the parsing. Earlier prototypes were implemented in Common Lisp and Python.
What can it be used for?
Security protocols, or any protocol structure that involve composition and transformation. Obol is interpreted, and protocols can very easily be upgraded. The runtimes modular structure allows for new message representation formats, cryptographic primitives, communication technology and so on, to be added dynamically.
What does it look like?
As an example, consider the typical way a message in a security protocol is described:
A ? B: A, B, {A, B, Na}Kab
The above means that A sends B a message consisting of the senders name, the intended recipients name, and then encrypts a repetition of the names along with a nonce Na(random value) using the shared-key Kab. We have not made the assumption that Obol must run on both protocol endpoints, so we must implement both sides (both A and B):
A side (send B A B (encrypt Kab A B Na)
B side (receive A A B (decrypt Kab A B *Na))
In the above example we assume that A and B know about each other, and that share the key Kab. However, the nonce Na is unknown to B, so B cannot recognize it, but can assign the unknown datum to a symbol, which is what the *Na construct does.
How can Obol be used?
An application must connect to the Obol runtime and request that it starts an Obol protocol, or script. The application receives a handle which it can use to communicate with the script instance, i.e. starting and stopping the protocol execution, setting and retrieving values the script requires and provides.
Enhancements:
Fixes:
- Jar file trouble
- robustness issues
- symbol property dereferencing

jcpp is a Java C preprocessor.

The C Preprocessor is an interesting standard. It appears to be derived from the de-facto behaviour of the first preprocessors, and has evolved over the years. Implementation is therefore difficult. JCPP is a complete, compliant, standalone, pure Java implementation of the C preprocessor.

It is intended to be of use to people writing C-style compilers in Java using tools like sablecc, antlr, JLex, CUP and so forth. This project has has been used to successfully preprocess much of the source code of the GNU C library.

The license is GPL-2. Subversion access is available on request. Less restrictive licenses are freely available on request, but please ask, because I want people to use this software, but Im curious to know who is using it and for what purpose.