Cell ➞ Java compiler version 0.5
Version 0.5 of the Cell to Java code generator is now available, and it's the first version that is meant for actual real-world use. It's still a beta version, but it's feature-complete in the sense that everything that was planned for version 1.0 has now been implemented, and the only thing that's missing now is just more testing.
This release brings a number of syntactic changes, improvements to the interface of the generated code, better support for debugging, and a minimal standard library with documentation.
The first change is in the syntax of partial membership testing and lookups on relations and mutable relation variables:
There have been changes to set/relation comprehension expressions:
There have also been changes to for loops that iterate over binary or ternary relations:
Note that the syntax for iterating over a sequence of tuples has not changed:
When iterating through a sequence of tuples or a relation you can now also replace variables you aren't going to use with an underscore, with both comprehension expressions and for loops:
and the same goes for destructuring assignments:
Interface of generated code
There have been two main sets of improvements to the interface of the generated classes. The first one is that each message handler is now mapped its own specific method. For example, given the following automaton:
the interface of the generated Java class now looks like this:
The last four methods allow you to invoke each of the message handlers directly, whereas previously you could only call them using the generic
These handler-specific methods are a lot faster and often more convenient. The generic
execute(..) method is still there though, since there are times when the ability to generically send messages of any type is crucial.
The second improvement is in the mapping of Cell types to Java types. The Cell types
[K -> V] are now mapped directly to
java.util.HashMap. Moreover, the
Maybe type now gets some special treatment too: a type like
Maybe[String], for example, is now mapped directly to the Java
String class, and the value
nothing is mapped to the Java
As part of this redesign the old
net.cell_lang.Value has been eliminated, and now any type that the compiler fails to map to an ad-hoc Java type is returned in textual form. That can make in some cases the generated classes less convenient to use, but since with every new release the use of
net.cell_lang.Value had become increasingly rare, I felt it just wasn't worth keeping around. In the future a small Java library will be provided for those rare cases where you need to parse the returned data.
Check the interfacing with Java page for all the details.
Debugging relational automata
When a message handler fails, it's now possible to figure out what caused the failure, which was very hard to do in previous releases. For that purpose, a new builtin procedure,
Error(..), is provided, which takes as argument an automaton instance and returns a
String that explains the cause of the failure of the last message handler to execute. Here's an example:
You can find the details in the using relational automata page.
The core standard library is now documented here. The library is minimal at the moment, and its documentation is still in a pretty rough form, but both will be gradually expanded and improved in the coming months.