Getting started

The Cell compiler can be downloaded here. After you unzip the file, you'll see five directories: bin, stdlib, examples, src and sublime-text. The first one contains the Cell compilers/code generators (there's one for each target language), the second one the standard library (which at the moment consists of just one file, prelude.cell), and the third one a few ready-to-build examples to get you started. To create your own project, just pick the one of them and start making changes to it. You can find more information about them in examples/README.txt.

Each of the code generators produces, when the compilation process is successful, one or more source files in the target language. These files can then be fed directly to a compiler for the corresponding language if your Cell source code includes a Main(..) procedure, or otherwise included in an existing project.

There's no documentation for the standard library yet, you'll have to delve into the prelude.cell file, which is very small anyway.

The sublime-text directory contains syntax highlighting files for Sublime Text. Just copy them in the ~/.config/sublime-text-3/Packages/User directory on Linux, or its equivalent in other operating systems.

Debugging

There's no debugger for Cell, and debugging is done mainly by tracing the execution of a program with the help of the print statement. Another useful tool is the assert statement. When an assertion fails, the execution of the program is stopped and all the variables in scope are printed to the standard output or to a file, if they are too large. If the program is running in debug mode (more on that in a second) the call stack is also printed, along with the value of all the arguments of all function calls on it. Call stack and values of function arguments are also printed every time the program crashes, for whatever reason (again, this happens only if the program is running in debug mode). Only a small part of this data is actually written to the standard output, with the rest of it being written to a set of files. All the files created by a program crash are created inside the debug subdirectory of the working directory of the process. This subdirectory is not created automatically: you have to create it manually before running the code, otherwise no dump file will be produced.

Sometimes there's no choice but to debug the generated code. The code itself is all but incomprehensible, but the names of variables and functions are the same as in the Cell sources, with the addition of a short suffix that is needed to avoid name clashes. For example a two-argument non-polymorphic function named my_fn(..) in Cell will be named my_fn_F2(..) in the generated code, and a variable named my_var will become my_var_V. How to print the value of a variable containing/pointing to a Cell object is language-specific, and is described in the following sections.

C++

The output of the C++ code generator (cellc) is the generated.cpp source file. You'll need a compiler that supports C++11. If your project defines any automata, of either type, the compiler will also produce a second files, generated.h, which contains the declaration of the interface of the generated classes that you'll be dealing with from your own native C++ code.

The C++ code generator is provided as a Linux binary, but if you're using another Unix-like platform like OS X/macOS you can try to compile it yourself using the source code in src. If you're using GCC you can build it by just typing g++ -O3 -DNDEBUG cellc.cpp -o cellc in src and then replacing the executable in bin with the one you built yourself.

The NDEBUG preprocessor symbol is used to choose between debug and release mode. It's the same symbol used by the C assert(..) macro. Defining it when compiling the generated C++ code will disable all the extra debugging code. With GCC, that can be done with the -DNDEBUG command line argument. The code compiled in debug mode is an order of magnitude slower, so make sure that symbol is defined when building your production binaries.

To print the value of a Cell variable my_var (which, as explained before, will be named my_var_V in the generated code) in GDB you'll need to type call print(my_var_V) at the debugger prompt.

Java

The Java code generator is provided as a jar file, cellc-java.jar. To run it, just type java -jar cellc-java.jar <project file> <output directory>, assuming cellc-java.jar is in the current directory . The compiler will produce a Generated.java file containing the core logic, and a separate file for each of the public classes you'll be interacting with. Their interface is documented in pseudo-Java code in another generated file, interfaces.txt.

In order to compile your code in debug mode, and have it print a complete stack trace when an error occurs, you'll have to use the -d option of the compiler: java -jar cellc-java.jar -d project.txt. Execution times normally increase by less than 50% in debug mode.

If you want to inspect the content of a variable containing a Cell object when debugging the generated code, just print the output of its toString() method.

C#

The C# code generator (cellc-cs.exe) generates a single file named generated.cs. Here too interface of the generated classes you'll have to interact with is documented in pseudo-C# code in the generated text file interfaces.txt.

The C# code generator should work on any platform that support .NET, through either the Microsoft or Mono implementation.

In order to compile your code in debug mode, and have it print a complete stack trace when an error occurs, you'll have to use the -d option of the compiler: cellc-cs.exe -d project.txt. Execution times approximately double in debug mode.

If you want to inspect the content of a variable containing a Cell object when debugging the generated code, just print the output of its ToString() method.