archives

Tom 2.4 Released

Tom 2.4 was released today, and contains many improvements. In particular, it is possible to generate with the Gom tool unmutable typed tree data structures with invariants, such as ordered lists, duplicate removal or even distributivity of balanced trees.
Also the new reflexive strategies allow self modifying and dynamic strategies in Java, and the easy use of strategic programming in a Java environment. This allows for instance the easy development of a Just in Time compiler for those strategies, using bytecode rewriting.

Quoting the announce:

Tom 2.4 announcement
--------------------

It is our great privilege and pleasure to announce the availability of
Tom version 2.4.

This release continues our work on the integration of pattern matching
and rule based programming facilities into C and Java.

Tom is a pattern matching compiler developed at INRIA. It is
particularly well-suited for programming various transformations on
trees/terms and XML based documents. Its design follows our research on
the efficient compilation of rule based languages (e.g. ELAN, developed
at INRIA-Loria).

Many applications have been developed in Tom. Among them, let us mention:
- the Tom compiler itself
- languages semantics, interpreters and program transformation tools
- a Just In Time strategy compiler using dynamic Java bytecode
transformation
- a generator of canonical abstract syntax trees (Gom)
- a proof assistant for supernatural deduction
- a compiler algorithm for anti-pattern matching and disunification

Tom is a complex compiler which adds powerful constructs to C and Java:
non linear syntactic matching, associative matching with neutral element
(a.k.a. list-matching), XML based pattern matching, string matching, and
equational rewriting.
This offers the possibility to analyze and transform any kind of
data-structure. Tom can be used for large scale developments and
applications. It comes with documentation, programming, and debugging
support.

This new release contains many improvements and new features:
- Anti-Patterns:
Tom now supports not only pattern matching, but also anti-pattern
matching. For example, the pattern (_*,!a(),_*) denotes a list
which contains at least one element different from a(). In a similar
way, !(_*,a(),_*) denotes a list which does not contain any a().

- Reflexive Strategies:
A strategy is now a term that can be matched like any other term.
This allows to dynamically build or transform a strategy at runtime.

- Congruence Strategies:
Gom generates new elementary congruence and constructions
strategies. This allows for instance to define the Map operation in
a easy way: map(s) = _conc(s)

- Java Bytecode:
A support for Java bytecode analysis and transformation is available
in the runtime library. This allows class loading, bytecode analysis
and transformation in an algebraic framework.
Using the strategy language, the control flow graph can be explored
and visualized using dot.

- Eclipse Plugin:
It is back for Eclipse version 3.2.
It also supports Gom and all new functionalities.

Tom is available, in open source (GPL/BSD License), from the web page:

http://tom.loria.fr

Best regards,
Tom development team

Google Code Search

As spotted over on Haskell-cafe, Google Code Search is now available! Of course, someone immediately noticed that Haskell was not yet supported (see the drop down list on the advanced search page), so they asked. If your favourite language is missing (Ehud will be pleased, Ada is already there), ask!

Interestingly, Lua is already there. And I have never heard of Limbo before?

Assembly language for Power Architecture

The first in a planned series of articles that introduces PowerPC ASM.
Assembly language for Power Architecture, Part 1: Programming concepts and beginning PowerPC instructions

Starting with this introduction to assembly language concepts and the PowerPC instruction set, this series of articles introduces assembly language in general and specifically assembly language programming for the POWER5.
It could just be me, but I think the ASM designers could've afforded to make this stuff a bit more human consummable - the preference is on the side of terseness:

li 0, 1
mr 3, 6
ld 6, 0(4)

Could be expressed a little cleaner as:

load R0, #1
load R3, R6
load R6, #0(R4)

No need for seperate instruction names for operations that are only different in how they load the data. And a clearer delineation of what is a register and what is a constant value. But then my bias for MCC68k is probably showing through. And the extra character for registers probably just makes higher level PL compiled code larger. (Oh well, easy enough to write a pretty viewer if one is so inclined.)