Farango¶

Empty types¶

An empty type is an abstraction on the concept of “nothing”. A variable with an empty type always hold a value representing “nothing”.

Value of empty types are not compatible between each other.

empty-type = type-prefix ;

Primitive types¶

The following types are known as primitive types:

• int (64-bit integer)
• float (64-bit double precision floating point number)
• bool

primitive-type = "int" | "float" | "bool" ;

Structure types¶

Structure types are records that contain one or more fields. Each field is denoted by an identifier that is unique to the record, and a type.

structure-type = type-prefix "=" "{" field-list "}" ;

field-list = field
           | field ";" field-list ;

field = identifier ":" type-identifier ;

Union Types¶

Union types denote an abstract type representing the logical union of all the specified types – a value with a type that is contained within an union can fit in a variable of this union type.

union-type = type-prefix "=" type-list ;

type-list = type-identifier
          | type-identifier "|" type-list ;

Binary Operators¶

Binary operators are operators taking two parameters. Invoking an operator can be done with two possible syntaxes:

• Operator-like: <expr> <op> <expr>
• Function-like: (<op>)(<expr>, <expr>)

The language shall natively provide the following operators:

Unary operators¶

Unary operators, unlike binary operators, only take one parameter.

The language shall natively provide the following operators:

Operator precedence¶

Operators in an expression have evaluation priority: this is called precedence. An operator takes precedence over an other operator if it is evaluated before the other. As an example, * takes precedence over +, because a + b * c can be expanded to a + (b * c), and not (a + b) * c.

Below is a table of operators sorted from high precedence (top) to low precedence (bottom):

User defined operators¶

User may define or overload operators by declaring a function with the operator symbol enclosed in parenthesis as identifier:

fun (<>)(lhs, rhs) = {
    lhs != rhs
}

Here we declare the binary operator <> as an alias of !=. Alternatively, one could implement the operator as:

var (<>) = (!=)

There are no requirements on the purity of user-defined operators, but programmers should aspire to make their operators pure.

There are also no requirements on operators laws, with some exceptions on default operator overloads:

• +, *, ^, |, &, == and != shall be associative and commutative.
• All comparison operators shall be transitive.

Declaration¶

A callable can be declared with the following syntax:

function = "fun" identifier "(" parameter-list ")" "=" expression ;

parameter-list = parameter
               | parameter "," parameter-list ;

parameter = identifier | identifier ":" type-identifier ;

which yields:

fun <identifier>(<param0>, <param1>, [...], <paramN>) = <expression>

where <identifier> is the name which the callable shall be refered to in the module, <param0> through <paramN> are the identifiers of each parameter, and <expression> is the expression that shall be evaluated when the callable is invoked.

Invokation¶

Callable invokation is done by specifying its identifier, then the list of its parameters enclosed in parenthesis:

<identifier>(<param0>, <param1>, [...], <paramN>)

Purity¶

A callable is called pure when it has no side-effects, and when given a set of parameters, two invokations does produce the same return value.

A common example of pure callables are the arithmetic operators.

Functions¶

Functions are the default (and most used) kind of callables. It has an internal context that is the parameters and local variables, and is destroyed when a return value is produced.

Coroutines¶

Coroutines are the second kind of callables, and can be inferred from the usage of the yield control flow keyword. They are much like functions, except that the internal context of the function is not discarded when a return value is produced. Instead, the context is saved, and the coroutine shall resume when it is invoked again later.

Tasks¶

Tasks are the final kind of callables, and they express a way to make asynchronous tasks units that can be passed on different execution environments. Tasks can be inferred from the usage of the offer control flow keyword, and much like functions, their execution context is destroyed after a return value has been offered.

Control Flow¶

In addition to the standard control flow statements, the following statements are provided to change the control flow in any callable:

• return <expr>: returns the value of the given expression in a function. Execution of the current function stops.
• yield <expr>: yields the value of the given expression in a coroutine. Execution resumes after this point when the coroutine is called again.
• offer <expr>: offers the value of the given expression in a task to the underlying task manager. Execution of the current function stops.