How to translate code?

To translate a Citrine program from one language into another:

ctr -t en2nl.dict myprogram.ctr

Dictionaries have the following format:

t "SOURCE" "TARGET"
s "SOURCE" "TARGET"
d "SOURCE" "TARGET"
x "SOURCE" "TARGET"

Use t for tokens and s for strings. There are 2 special translation pairs: the decimal separator (d) and the thousands separator (x). To generate a dictionary from 2 versions of Citrine in different languages:

ctr -g /nl/dictionary.h /en/dictionary.h

Test-o-Mat

The Citrine code base is tested using the Test-o-Mat framework which ships with Citrine. The Test-o-Mat system is very simple to understand and work with and can also be used to test other software. The basic idea is that you have test definitions and expectation files (.exp). After loading the test framework, override the next-message to generate a new test specification object and override the process-message of the Test Suite to describe how the test should be processed. For a detailed example you can look at test no. 365 in the test folder (tests/test0365.ctr). The Test-o-Mat framework is only available in the English language at the moment. In the example below (based on that test) we simply compare the contents of the test file with itself using a the UNIX cat-command:

Program use: Path Test-o-Mat Package.
☞ number of tests ≔ 1.

Tests path: ‘’.
☞ test suite ≔ Tests new.

test suite on: ‘next’ do: {
	☞ test ≔ Nil.
	(⚿ counter < number of tests) true: {
		test ≔ Test new
			number: ⚿ counter copy,
			name: ‘test0365.ctr’,
			file: ‘test0365.ctr’.
	}.
	⚿ counter add: 1.
	↲ test.
}.

test suite on: ‘process:’ do: { :test
	☞ actions ≔ Tests actions.
	☞ action ≔ 
			Tests action
			command: Path cat,
			target: ‘../test0365.ctr’,
			output: Path tmp result,
			log: Path tmp log.
	actions 
		append: action,
		expect: ‘../test0365.ctr’,
		run or fail: ‘OK↵’.
}.
test suite run.

get  ≔ Request get: ‘ search’ .
list ≔ Request getArray: ‘ orders[]’ .
post ≔ Request post: ‘ message’ .
list ≔ Request postArray: ‘ orders[]’ .
file ≔ Request file: ‘ avatar’ .

Request 
host: ‘ localhost’  
listen: 4000
pid: ‘/var/run/storm.pid’  callback: {
	✎ write: ‘Content-type: text/html\n\n’ .
	☞ fname ≔ Program setting: ‘ DOCUMENT_URI’ .
	☞ script ≔ File new: ‘ /var/www/htdocs’  + fname.
	Program use: script.
}.

location ~ \.ctr$ {
        try_files $uri $uri/ =404;
        scgi_pass 127.0.0.1:4000;
        include   scgi_params;
}

How to start the core unit tests?

As of july, Citrine will feature a new unit test system to test the core of the language. Over the next few years, we expect to extend this test suite with all sorts of useful tests to improve the quality of the Citrine code. The unit test runner can be invoked simply from the language itself, using:

Program test.

This will start the internal unit test runner. After running all the unit tests the process will be stopped automatically. There is no way to continue a Citrine program after invoking the test runner. If a single test fails, the test suite will report the error and exit. The output from the unit test runner might look like this (although this will change from release to release):

Running Internal Tests
[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27]...

The unit test system is included in the regular test suite and currently resides in test file 0356. The unit test system is used to test parts of Citrine that are difficult to test from the outside like the inner workings of the Lexer, Parser, Walker, as well of specific system utilities for memory management and encoding.

AST-Export

Citrine allows you to export the AST representation of any Citrine program so you can transpile or compile it to any other target language, including for example: machine code, Assembler, C, C++, Java, Lua, SQL, PHP, Perl or JavaScript.

To generate an AST-export:

ctrXX -x program.ctr

XX = your language edition

The output looks like:

52;0;0;;[57;0;3;✎;;55;0;6;write:;[56;0;5;Hello;;];];52;0;0;;[57;0;3;✎;;55;0;6;write:;[56;0;6;World!;;];];79;0;0;;;

The original program:

✎ write: ‘Hello’.
✎ write: ‘World!’.

The format for the AST-export is as follows, each node in the tree is represented as:

{TYPE} ; {MODIFIER} ; {LENGTH OF VALUE BUFFER} ; {VALUE BUFFER} ; {NESTED NODES}

Nested nodes are between [ and ].

Opcodes for nodes:

Code	Type of AST-node
51	Assignment
52	Message expression
53	Unary Message
54	Binary message
55	Keyword Message
56	String Literal
57	Object Reference
58	Numeric Literal
59	Code Block Literal { }
60	Return Statement ↲
76	Parameters
77	Instructions in a Code Block
78	Parameter (in the parameters)
79	End of Program
80	Nested Expression between (...)

Modifiers:

Code	Meaning
0	Variable: x
1	Property: ⚿ x
2	Declaration: ☞ x ≔

To test the AST-export you can pipe it through the example program 'info' (available in the source tree in misc/tools):

ctrXX -x program.ctr | info

Message Object Reference(✎) Keyword Message(write:) String Literal(Hello) Message Object Reference(✎) Keyword Message(write:) String Literal(World!) End

Go back to homepage.