Free asts software for linux

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.

Template::Ast is a Perl module to process ASTs for Perl Template Toolkit.

SYNOPSIS

use Template::Ast;

# Rebuild AST stored in file:
$ast = Template::Ast->read(foo.ast) or
die Template::Ast->error();

# Writing existing AST to file:
$ast = { Marry => [24, F], John => [21, M] };
Template::Ast->write($ast, foo.ast) or
die Template::Ast->error();

$ast = Template::Ast->merge([1,2,3], undef); # [1,2,3]
$ast = Template::Ast->merge(undef, [1,2,3]); # [1,2,3]
$ast = Template::Ast->merge(undef, undef); # undef

$ast = Template::Ast->merge({A=>1,B=>2}, [C]); # [C]
$ast = Template::Ast->merge([1,2,3], [5,6]); # [5,6]
$ast = Template::Ast->merge([{A=>1},2], 5); # 5

$ast = Template::Ast->merge({A=>1,B=>2}, {C=>3}); # {A=>1,B=>2,C=>3}
$ast = Template::Ast->merge({A=>1,B=>2}, {B=>3}); # {A=>1,B=>3}

# {A=>1,B=>2}
$ast = Template::Ast->merge({A=>1,B=>undef}, {A=>undef,B=>2});

Template::Ast->merge(
{A=>1,B=>{C=>1,D=>2}},
{B=>{C=>1,D=>3,E=>4}}
); # {A=>1,B=>{C=>1,D=>3,E=>4}}

Template::Ast->merge(
{A=>1,B=>{C=>[1,2]}},
{B=>{C=>[3,4]}}
); # {A=>1,B=>{C=>[3,4]}}

print Template::Ast->dump([$vars], [vars]);

ASTs are essential in the programming model based on Perl Template Toolkit. This module provides some easy interface to do the dirty work involved in AST handling. The term AST used here are referred to any Perl referece pointed to a complex data structure, such as a nested hash, a nested array, or such.

X10 project is a new object-oriented, type-safe programming language for programming the next generation of high performance systems. X10 is designed and developed by IBM.
While developed in close contact with the designers of X10 at IBM there are significant differences in syntax and semantics between the (current) IBM prototype and language specification. Those differences arise primarily from the fact that the X10-XTC compiler attempts to implement what might be close to the (non-existant) 0.5 specification of the language, whereas the IBM reference implementation targets the 0.41 specification.
We hope that 0.5 will add operator overloading, generics and region types and thus the X10-XTC compiler is build trying to support these concepts.
Another key difference is that the current X10-XTC compiler does not support close integration of X10 code (however, Java code can be called using classes that are declared to be extern). On the technical side, the IBM compiler compiles X10 code to Java source code which is then compiled to Java bytecode by javac.
The XTC-X10 compiler produces Tucson IR which is currently interpreted by an interpreter written in Java (but is supposed to be compiled to C or native code in the future). The reason is that Tucson IR will hopefully be easier to compile and optimize compared with Java ASTs. As a result, equivalent X10 code should run slower with XTC-X10 today, but might run as fast as UPC code once we are a bit further along.
Enhancements:
- This release fixes some minor bugs in the code generator for atomic sections.
- The type checker was improved substantially and now works for simple distribution operations.
- In addition to the X10 compiler front-end and interpreter backend, a new backend that generates C code was started.
- The new C backend already supports constants, (virtual) calls, exceptions, branches, allocation, and get/put operations.