TL;DR The QED syntax is mostly inspired by C, except for the GUI part which looks more like a markup language (without tags). Here we focus on code syntax.

Before detailing what makes QED different from other languages, let’s first show the similarities to get ready for the GUI and other novelties with a firm ground. The QED syntax borrows heavily from the C syntax. Skip this section if you feel confident to dive straight into the new stuff; you may come back here anytime for specific details.

Hello, World!

Although QED is a programming language with a compiler, it may act as a scripting language as shown in the various demos below. Of course, we’ll start with the traditional “Hello, World!” to assess the language simplicity. It is a two-liner but you may try out this code with only one of the two lines, depending of what you want. Click Run to execute it.

The first line is a console version of the application, whereas the second line is a GUI version (both versions can coexist). The GUI version is shown on top-right section and the console version is output at bottom-right.

I know I’m already digressing here with some GUI code but don’t worry, we won’t see more of it in this section. I just wanted to show you a quick glimpse of QED output possibilities because, well, this is the venerable “Hello, World!” app and it had to showcase both output media.


Statements in QED are delimited by a newline character or by a semicolon (which allows multiple statements to share one line).

Depending on your preference, you may add one or more semicolons at the end of a line without any adverse effect.

You can split a statement into multiple lines but be careful though; because semicolons do not mark the end of a statement, there are rules to follow. For instance, when splitting a binary expression, put the operator at the end of the first line, not at the beginning of the second line, like this:

Here, on the second line, if the plus sign was moved on the next line (“+ 5”), QED would split this statement into two statements, namely println("3 + 5 = " + (3 and +5 (also, an error would be generated for the first statement). So operators must end one line to indicate the statement continues on the next line.

Variables and primitive types

Variables in QED are almost similar to their C/Java counterparts. A variable definition begins with a type, followed by a name and ending with an optional initialization expression. The primitive types are less numerous though: bool, String, int and float (the latter two using 64 bits). When not initialized, their default value is false, "", 0 and 0.0 respectively.

There is another keyword to introduce: var. A variable declared as var will infer its type based on its initialization value type. Its type cannot change afterwards.

However a var variable with no initialization value can hold any value from any type (a bit like a void* in C).

Control statements and blocks

The usual if-else, while, for control keywords are available in QED.

As in C or Java, braces {} are used to delimit multiple-line blocks. There is no need for a set of braces when a block consists of a single statement. Also, blocks define scoping rules for variables and functions. Empty blocks must be explicitly defined using {} (a semicolon after a control statement won’t work).

The only caveat is there is no break statement in QED as of this writing. Also the switch-case statement is not yet implemented.


Again, functions are defined the same way as in C.

type name(type1 parm1, type2 parm2, ...) {

Unlike C though, nested functions are allowed and closures are fully supported.

Functions are first-class citizens in QED. Functions types can be defined with any function, leaving their body empty. Then you can use them as types if followed by a star (the semantics are very different from C here.

When used as lambdas, functions must always be embedded in a set of parentheses. You may use any function name but the preference would be lambda or l for clarity.

As a sidenote, for plain functions, the first alphabetic character must be lowercase. Uppercase-beginning “functions” do exist in QED but define something slower but much more powerful as we’ll see next. When used as types (with a * suffix), keep the names’ first letter lowercase.


We can almost add the types in this sections but they are a bit different from

Explicit Arrays

The next steps

Based on what we’ve seen, we almost have a full-fledged language. Even if types are not defined, closures can be used to emulate them. But QED can do much more, as we’ll next with new constructs and ultimately, GUI support. This is where QED begins to drift away from other languages.