Free yacc software for linux

yagg, given YACC-like and LEX-like input files, generates a C++ program that generates all strings of a user-specified length. yagg can then be used to generate inputs for testing, or to validate that a grammar accepts the strings that you think it does.
The grammar file provides the grammar productions for string generation, along with optional action blocks that can perform context-sensitive checks in order to limit the generated strings. The LEX-like terminal generator file provides specifications that instruct the program how to generate strings for terminals in the grammar.
Enhancements:
- Added a section to the tutorial on controlling output formatting. (Thanks to Casiano Rodriguez Leon for the question.)
- Fixed a misspelling in the hexadecimal examples README.
- Updated the makefile version
- Fixed an assert failure that would occur if (1) a rule list has more than one nonterminal, (2) some nonterminal in the list except the last one had no strings for a given allocation, and (3) the last nonterminal had strings for the given allocation.
- Updated the Makefiles
- Updated the test cases for the pass-by-reference updates in 1.3000.
- Make it possible to call Print_Strings from anywhere in the program for debugging. Maybe Ill add a flag for it later.
- Added RBD example

Radstock is a tool to analyse RADIUS traffic on high volume radius servers. It has the ability to fully decode each packet, and also has extensive filters capabilities to allow you to selectively match RADIUS packets.

It provides the ability to fully decode each packet. Here is some sample output.
The key feature of radstock is its ability to filter the packets shown based on any attribute. It will also listen out for responses to matched packets and display these as well. An example filter would be (all on one line):

radstock -e "(user-name = paul or user-name = bob) and exists nas-port-id"

To compile radstock you need the following libraries:

libpcap
flex or lex
bison/yacc

Once you have these, the following three commands should do just about
all you need.

/configure
make
make install

It has been successfully compiled on Linux and Solaris
platforms. Whether it works on them is a completely different story.

Styx is a scanner and parser generator designed to address some shortcomings of the traditional lex/yacc combination.
It has unique features like automatic derivation of depth grammar, production of the derivation tree including its C interface which provides access to the abstract syntax tree, preservation of full source information and pretty printing to faciliate source-source translation, persistence to aid rapid interpreter writing.
For application in contemporary computing environments, it supports unicode, reentrancy and offers thread-safeness.
Last but not least, Styx works well under many different OSes, among them dos, windows, and serveral unixes.
It has been successfully used in many applications and is known to provide rapid compiler development. Both from our practical experience as well as from the amount of written code, the gain in development time for realistic languages versus lex/yacc is a factor of about 5-10.
Enhancements:
- fixes panic mode error recovery
- fixes token buffer restriction. The token length is now of type long.
- hopefully fixes some configure problems on freeBSD (concerning libdl)
- adds parsing support for binary files

A practical lambda-calculator is a normal-order evaluator for the untyped lambda-calculus, extended with convenient commands and shortcuts to make programming in it more productive.

Shortcuts are distinguished constants that represent terms. Commands define new shortcuts, activate tracing of all reductions, compare terms modulo alpha-conversion, print all defined shortcuts and evaluation flags, etc.

Terms to evaluate and commands are entered at a read-eval-print-loop (REPL) "prompt" or "included" from a file by a special command. A Haskell branch is an embedding of the lambda calculator (as a domain-specific language) into Haskell. The calculator can be used interactively within Hugs or GHCi.

The present calculator implements what seems to be an efficient and elegant algorithm of normal order reductions. The algorithm is "more functional" than the traditionally used approach.

The algorithm seems identical to that employed by yacc sans one critical difference. The calculator also takes a more "functional" approach to the hygiene of beta-substitutions, which is achieved by coloring of identifiers where absolutely necessary. This approach is "more functional" because it avoids a global counter or the threading of the paint bucket through the whole the process. The integration of the calculator with Haskell lets us store terms in variables and easily and intuitively combine them.

The traditional recipe for normal-order reductions includes an unpleasant phrase "cook until done". The phrase makes it necessary to keep track of reduction attempts, and implies an ugly iterative algorithm. Were proposing what seems to be an efficient and elegant technique that can be implemented through intuitive re-writing rules.

Our calculator, like yacc, possesses a stack and works by doing a sequence of shift and reduce steps. The only significant difference from yacc is that the lambda-calculator "reparses" the result after the successful reduce step. The source and the target languages of our "parser" (lambda-calculator) are the same; therefore, the parser can indeed apply itself.

The parsing stack can be made implicit. In that case, the algorithm can be used for normalization of typed lambda-terms in Twelf.

The following examples show that lambda-calculus becomes a domain-specific language embedded into Haskell:

> c0 = f ^ x ^ x -- Church numeral 0
> succ = c ^ f ^ x ^ f # (c # f # x) -- Successor

> c1 = eval $ succ # c0 -- pre-evaluate other numerals
> c2 = eval $ succ # c1
> c3 = eval $ succ # c2
> c4 = eval $ succ # c3

It is indeed convenient to store terms in Haskell variables and pre-evaluate (i.e., normalize) them. They are indeed terms. We can always ask the interpreter to show the term. For example, show c4 yields (f. (x. f (f (f (f x))))).

let mul = a ^ b ^ f ^ a # (b # f) -- multiplication
eval $ mul # c1 ---> (b. b), the identity function
eval $ mul # c0 ---> (b. (f. (x. x))), which is "const 0"

These are algebraic results: multiplying any number by zero always gives zero. We can see now how lambda-calculus can be useful for theorem proving, even over universally-quantified formulas.

The calculator implements Dr. Fairbairns suggestion to limit the depth of printed terms. This makes it possible to evaluate and print some divergent terms (so-called tail-divergent terms):

Lambda_calc> let y_comb = f^((p^p#p) # (c ^ f#(c#c))) in eval $ y_comb#c
c (c (c (c (c (c (c (c (c (c (...))))))))))

It is amazing how well lambda-calculus and Haskell play together.

Nasal is a language that I wrote for use in a personal project. Ostensibly it was because I was frustrated with the dearth of small-but-complete embeddable scripting languages, but of course I really wrote it because it was fun.
It is still young and incomplete in a few places, but is under active development and has been integrated as the extension language for the FlightGear simulator.
Documentation is still sparse. There is a design document available, which talks at length about the "whys" behind the design of Nasal and includes documentation for the built-in library functions.
More useful to the experienced programmer is the tutorial-style sample code, which explains and demonstrates all the syntax features of the language.
Like perl, python and javascript, nasal uses vectors (expandable arrays) and hash tables as its native data format. This is a well-understood idiom, and it works very well. I felt no need to rock the boat here.
Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks.
Like perl, but unlike python, hash keys must by scalars in nasal. Python supports a "tuple" constant type that can be used as well, but there is no equivalent in nasal (you cant use vectors as keys because they might change after the insertion).
Like perl and python, nasal uses a # character to indicate and end-of-line comment. There is no multiline begin/end comment syntax as in Javascript.
Like perl, nasal functions do not have named parameters. They get their arguments in a vector named "arg", and can extract them however they like. Unlike perl, Nasal takes advantage of this feature to do away with function "declaration" entirly; see below.
Like python, there is no hidden local object scope in a function call. The object on which a method was called is available to a function as a local variable named "me" (python calls this "self" by convention, but because nasal has no declared function arguments, there is no opportunity to change it).
Like perl, "objects" in nasal are simply hash tables. Looking an item up by name in a hash table and extracting a symbol for an object are just different syntax for the same operation (but read on for an important exception):
a["b"] = 1 means the same thing as: a.b = 1
The above paragraph is a minor lie. The "dot" syntax is also the clue to the interpreter to "save" the left hand side as the "me" reference if the expression is used as a function/method call. That is, these expressions are not equivalent (one is a plain function call, the other a method invocation on the object "a"):
a["b"](arg1, arg2) isnt the same as: a.b(arg1, arg2)
Like javascript, nasal lacks a specific "class" syntax for OOP programming. Instead, classes are simply objects. Each object supports a "parents" member array; symbol lookup on the object at runtime bounces to the parents (and the parents parents) if the symbol is not found in the hash. The parents field is just like any other object field, you can set it however you like and even change it at runtime if you are feeling especially perverse.
Like lisp, javascript and perl, nasal supports lexical closures. This means that the local symbol namespace available to your function when it is assigned remain constant over time. If you dont know what this means, you dont need to care. It is this feature that allows functions to use variables declared in the outer scope when it is defined (e.g. seeing "module" variables).
Like all other scripting languages, functions are just symbols in a namespace, but unlike all other scripting languages, there is no function "declaration" syntax. A function is always an anonymous object (a "lambda," in the parlance), which you assign to a variable in order to use. Like so:
myfunction = func { arg[0] + 1 }
myfunction(1); # returns 2
One annoyance of this feature is that Nasal functions dont have unique internal "names". So a debugging or exception stack trace can only give you a source line number, and not a function name as reference.
Nasal has a straightforward, readable syntax which is closest to javascript among other scripting languages. Like later versions of javascript, it includes has a hash lookup syntax as well as an object field accessor syntax (that is, you can do both a.b and a["b"]).
Unlike python, nasal has a grammar which is not whitespace-sensitive. This doesnt make python hard to write, and it arguably makes it easier to read. But it is different from the way the rest of the world works, and makes python distinctly unsuitable for "inline" environments (consider PHP, Javascript, ASP or in-configuration-file scripts) where it needs to live as a plain old string inside of another programs code or data file.
Nasal garbage collects runtime storage, so the programmer need not worry about manual allocation, or even circular references. The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a "return early" capability for latency-critical applications. The collector can be instructred to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the "small and simple" criteria and are not likely to be included.
Like python, nasal supports exception handling as a first-class language feature, with built-in runtime-inspectable stack trace. Rather like perl, however, there is no special "try" syntax for exception handling, nor inheritance-based catching semantics. Instead, you call a "try" function on another function, and inspect the return value on your own. Code simply calls die with an argument list, which is returned from the closest enclosing try() invocation. Elaborate exception handling isnt really appropriate for embedded scripting languages. [NOTE: this isnt finished yet]
Nasal tries to be stricter than perl. Operations like converting a non-numeric string value to a number, reading or writing past the end of an array or operating on a nil reference, which are generally legal in perl, throw exceptions in nasal. Perl sometimes bends over backwards to do something "reasonable" with your instructions (e.g. whats the boolean truth value of a hash reference?); nasal doesnt try ("error: non-scalar used in boolean context at line 92")
Nasal is very small, very simple, written in ANSI C, and generally an excellent choice for embedded applications. It uses a simple and transparent syntax interpretable by a simple "bracket matching and operator precedence" parser. It does not depend on any third party libraries other than the standard C library. It does not depend on third party tools like (f)lex and yacc/bison. It builds simply and easily, supports a reasonably simple extension API and cohabitates well with other code.
Nasal makes no use of the processor stack when running recursive code. This is important for embedded languages as it provides the ability to "exit early" from a Nasal context. An outside application may have realtime constraints, and Nasal can be instructed to run for only a certain number of "cycles" before returning. Later calls will automatically pick up the interpreter state where it left off.
Nasal provides "minimal threadsafety". Multithreaded operations on Nasal objects are safe in the sense that they cannot crash or corrupt the interpreter. They are not guaranteed to be atomic. In particular, poorly synchronized insertions into containers can "drop" objects into oblivion (which is OK from an interpreter stability standpoint, since the GC will clean them up normally). Race conditions have to be the programmers problem anyway, this is just another symptom. Garbage collection will block all threads before running. [NOTE: this part is still unimplemented.]
Enhancements:
- This release contains the updates that have been available in SimGear for some time now.
- Important new functionality includes bugfixes, many performance enhancements, a declared function argument syntax, a ternary (?:) operator, indexable and mutable string objects, interpreter thread safety features, and much work to the "standard" library (including stdio, bitfields, Unix system calls, and PCRE regular expressions).