CLAIRE's Roadmap



1. CLAIRE's Journal

2. Future Releases


4. Diffusion policy


1. CLAIRE's Journal: History of Previous Releases

History of feature upgrades in CLAIRE 2.x

Here are the main changes in the 2.1 release:

·              external functions must be characterized by three status flags instead of a boolean, in the function! Constructor

·              string buffers can be used with nth_get and nth_put.

·              Spying can be bound to entering into a given method (spy(p))

·              Id(x) forces the evaluation of x before compilation (useful to define global_variables)

·              Dynamic modules (with begin and end).

·              Interfaces are introduced (global_constant that represent unions) as a bridge towards Java.

Here are the main changes in the 2.2 release:

·               the reified properties (reify(p))

·              tracing and spying can be activated after a given number of call evaluation, using a call counter.

·              Rule modes exists, set and break have been introduced for a better control of the meaning of “existential” variables in logical rules.

·              x.p or p[x] are allowed as assertions in the logic if p is of range boolean.


Here are the main changes in the 2.3 release:

·              the stop statement (cf. later)

·              the profiler option –p

·              the check_range method


 2.4 release:

·              the array class.

·              the optimized compilation of float expressions


 2.5 release:

·              a new set of options for the shell compiler and the withdrawal of the –cf option.

·              A few new methods (look in the API for date!, time_read, vars, safe)

·              The removal of dynamic namespaces

·              The CLSMALL installation option is now provided  for users that do not require large class hierarchies.

·              Forward class declarations have stricter rules


Changes from CLAIRE 2.5  to CLAIRE 3.0

·         Lists and sets are strongly typed – this is THE major change. Because we do no longer rely on dynamic typing, the following is no longer true (in 3.0, but actually true in 3.2):  

         list(1,2,4) % list[integer]

Thus, migrating from 2.x to 3.0 is not an easy task. The proposed method is to get rid of all subtypes of the form list[x] or set[x] and replace them with parametric types list<x> and set<x> for slots and global variables, and with list of set for dynamic bag that are used within methods. This should be reasonably straightforward, although the updating of a slot or a variable that has a strong type now requires a value that is strongly typed as well. The second step is to re-introduce further typing for lists or sets that are used within methods, but this can be done progressively, as it is mostly an optimization.

·         Tuples are no longer lists, they are an independent subtype of bag. This should not cause any problems, unless you were using list methods on tuple – a really poor idea.

·         The external representation of floats uses the native “double” type. This should be totally transparent to you, unless you wrote C++ functions to implement some of your methods.

·         A number of features that were of little use have been removed:

1.        queries

2.        interfaces (the word takes a new meaning in v3.1 and onwards)


·              The interface(p) declaration is introduced to support much faster dynamic method calls

·              The interface(c,p1,p2,…) declaration is introduced to support the generation of C++ methods with member methods

·              The method PRshow(..) is introduced to give easy access to the profiling capabilities of CLAIRE

·              The optimizing pattern “for x in Id(s) e(x)” is introduced.


CLAIRE 3.2  

CLAIRE 3.2 is an interesting evolution of CLAIRE 3.0, since it actually makes the transition from 2.5 much easier. The key  change is the fact that types list[t] may apply to untyped list. Therefore, a CLAIRE 2.5 code fragment becomes valid and safe in 3.2, unless it performs updates on such a list. The major difference, from a migration point of view, is the fact that updates on untyped list are no longer allowed. The list of changes from 3.1 is as follows.

·              Lists now exist in two flavors: read-only untyped lists and typed lists, which support (safe) updates.

·              Propagation rules have been simplified dramatically. They are now reduced to simple event-propagation rules, but they are a standard feature of the CLAIRE language, as opposed to an external library, which was the case for version 3.0.

·              The debugger now checks the range of the method for each call, a long awaited feature !


CLAIRE 3.3 is a small evolution from 3.2, that is mostly designed for performance improvement. The main change is the optimization of global variables that are local to a module. A global variable is “local” when its name belongs to the module where the global variable is defined. In that case, CLAIRE generates a C++ native global variable, which is not accessible at the top-level but is managed faster. This optimization does not occur if the range is any, if the variable is defeasible, or if the content of the variable needs to be protected from garbage collection. The list of other changes from 3.2 is as follows.

·         sort(<method>,<list>)  is macro-expanded by the compiler using a quicksort algorithmic pattern, when sort(…) is used to define a method as in the following example:                                         
sortByValue(l:list<Task>) : list<Task> -> sort(byValue @ Task, l)

·         The compiler may produce optimization hints using the proper optimization mode. If the options –O and –v 1 are used, the compiler will generate notes when an optimization pattern was not used for lack of typing information.

·         The compiler enforces the Claire 3.3 syntax and issues a warning when an If statement is found which test expression does not return a Boolean, and when an equality expression is found which value is not used (probably meant as an assignment)

bulletThe default range for a method without range declaration is void. This small change may cause a lot of trouble when the user does not usually provide a correct range for her methods. The CLAIRE compiler is now more strict when checking that void values are not wrongly used in expressions (compiler error # 205).
bulletThe compiler is able to perform type inference and type checking on for and while statements that use a break(x) expression to return a value. Adding a value to a list is also better type-checked.


Changes from CLAIRE 3.3 to CLAIRE 3.4

CLAIRE 3.4 is the 20-th anniversary version of CLAIRE. It adds a few useful features to CLAIRE but its main goal is the migration towards newer development and code sharing tools, as well as  the port onto distributed environments such as cloud computing. Here is a short list of what’s new:

2. Future Releases

There are no planned releases of CLAIRE in the future. The version 3.3 had been stable (modulo the bug fixes) for ten years and the version 3.4 adds a small set of minor improvements (together with some bug fixes).


3. Libraries

This section will be expended thoughout 2014. My goal is to release a number of significant CLAIRE modules, mosty related to GTES (Game Theoretical Evolutionary Simulation)

4. Diffusion policy

CLAIRE is a fully open-source project since 2008. Both sources and binaries are available without any restrictions.