text:
<title>Céu 0.10 - Reference Manual - (warning, incomplete!)</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

Introduction
============

> *Warning:*
*This manual is under a rewriting process and still mostly reflects version 0.8.*

Céu is an imperative, concurrent and reactive language in which then lines of
execution, known as *trails*, react together continuously and in synchronous
steps to external input events from the environment.
Waiting for an event halts the running trail until that event occurs.
The environment broadcasts an occurring event to all active trails, which share
a single global time reference (the event itself).

The synchronous concurrency model of Céu greatly diverges from conventional
multithreading (e.g. *pthreads* and *Java threads*) and the actor model
(e.g.  *erlang* and *Go*).
On the one hand, trails can share variables in a deterministic and seamless way
(e.g. no need for locks or semaphores).
On the other hand, there is no real parallelism (e.g. multi-core execution) in
the standard synchronous execution mode of the language.

Céu integrates well with C, being possible to define and call C functions from
within Céu programs.

Céu is [free software](#license).

Synchronous execution model
---------------------------

Céu is grounded on a precise definition of *logical time* as a discrete
sequence of external input events:
a sequence because only a single input event is handled at a logical time;
discrete because reactions to events are guaranteed to execute in bounded real
time (see [Bounded execution](#bounded-execution)).

The execution model for Céu programs is as follows:

1. The program initiates the *boot reaction* from the first line of code in a
      single trail.
2. Active trails1, one after another, execute until they await or
      terminate.
      This step is named a *reaction chain*, and always runs in bounded time.
3. The program goes idle and the environment takes control.
4. On the occurrence of a new external input event, the environment awakes
      *all* trails awaiting that event.
      It then goes to step 2.

(1
*Trails can be created with [parallel
compositions](#parallel-compositions-and-abortion).*)

The synchronous execution model of Céu is based on the hypothesis that internal
reactions run *infinitely faster* in comparison to the rate of external events.
An internal reaction is the set of computations that execute when an external
event occurs.
Conceptually, a program takes no time on step 2 and is always idle on step 3.
In practice, if a new external input event occurs while a reaction chain is
running (step 2), it is enqueued to run in the next reaction.
When multiple trails are active at a logical time (i.e. awaking on the same
event), Céu schedules them in the order they appear in the program text.
This policy is somewhat arbitrary, but provides a priority scheme for trails,
and also ensures deterministic and reproducible execution for programs.
At any time, at most one trail is executing.

The program and diagram below illustrate the behavior of the scheduler of Céu:

 1:  input void A, B, C;
 2:  par/and do           // A, B, and C are external input events
 3:      // trail 1
 4:      <...>            // <...> represents non-awaiting statements
 5:      await A;
 6:      <...>
 7:  with
 8:      // trail 2
 9:      <...>
10:      await B;
11:      <...>
12:  with
13:      // trail 3
14:      <...>
15:      await A;
16:      <...>
17:      await B;
18:      par/and do
19:          // trail 3
20:          <...>
21:      with
22:          // trail 4
23:          <...>
24:      end
25:  end

![](reaction.png)

The program starts in the boot reaction and splits in three trails (a `par/and`
rejoins after all trails terminate).
Following the order of declaration for the trails, they are scheduled as
follows (*t0* in the diagram):

- *trail-1* executes up to the `await A` (line 5);
- *trail-2*, up to the `await B` (line 10);
- *trail-3*, up to `await A` (line 15).

As no other trails are pending, the reaction chain terminates and the scheduler
remains idle until the event `A` occurs (*t1* in the diagram):

- *trail-1* awakes, executes and terminates (line 6);
- *trail-2* remains suspended, as it is not awaiting `A`.
- *trail-3* executes up to `await B` (line 17).

During this reaction, new instances of events `A`, `B`, and `C` occur (*t1* in
the diagram) and are enqueued to be handled in the reactions that follow.
As `A` happened first, it is used in the next reaction.
However, no trails are awaiting it, so an empty reaction chain takes place
(*t2* in the diagram).
The next reaction dequeues the event `B` (*t3* in the diagram):

- *trail-2* awakes, executes and terminates;
- *trail-3* splits in two and they both terminate.

With all trails terminated, the program also terminates and does not react to
the pending event `C`.
Note that each step in the logical time line (*t0*, *t1*, etc.) is identified
by the event it handles.
Inside a reaction, trails only react to that identifying event (or remain
suspended).

### Parallel compositions and abortion

The use of trails in parallel allows programs to wait for multiple events at
the same time.
Céu supports three kinds of parallel compositions differing in how they rejoin
and proceed to the statement in sequence:

1. a `par/and` rejoins after all trails in parallel terminate;
2. a `par/or` rejoins after any trail in parallel terminates;
3. a `par` never rejoins (even if all trails terminate).

The termination of a trail inside a `par/or` aborts the other trails in
parallel, which must be necessarily awaiting (from rule 2 of [Execution
model](#synchronous-execution-model)).
Before aborting, a trail has a last opportunity to execute all active
[finalization statements](#finalization).

As mentioned in the introduction and emphasized in the execution model, trails
inside parallel compositions do not execute with real parallelism.
Therefore, inside compositions trails are *awaiting in parallel*, rather than
*executing in parallel*.

### Bounded execution

Reaction chains should run in bounded time to guarantee that programs are
responsive and can handle upcoming input events from the environment.
For any loop statement in a program, Céu requires that every possible path
inside its body contains at least one `await` or `break` statement, thus
avoiding *tight loops* (i.e., unbounded loops that do not await).

In the example below, the `if` true branch may never execute, resulting in a
tight loop (which the compiler complains about):

loop do
    if <cond> then
        break;
    end
end

For time-consuming algorithms that require unrestricted loops (e.g.,
cryptography, image processing), Céu provides [Asynchronous
execution](#asynchronous-execution).

### Deterministic execution

`TODO (shared memory + deterministic scheduler + optional static analysis)`

### Internal reactions

Céu provides inter-trail communication through *internal events*.
Trails use the `await` and `emit` operations to manipulate internal events,
i.e., a trail that emits an event can awake trails previously awaiting the same
event.

An `emit` starts a new *internal reaction* in the program:

1. On an `emit`, the scheduler remembers the statement following it to execute
later (i.e., its continuation).
2. All trails awaiting the emitted event awake and execute (like rule 2 for
external reactions).
3. The emitting trail resumes execution from its continuation.

If an awaking trail emits another internal event, a new internal reaction
starts.
The scheduler uses a stack policy (first in, last out) for saved continuation
statements from rule 1.

Example:

1:  par/and do
2:      await e;
3:      emit f;
4:  with
5:      await f;
6:  with
7:      ...
8:      emit e;
9:  end

The `emit e` in *trail-3* (line 8) starts an internal reaction that awakes the
`await e` in *trail-1* (line 2).
Then, the `emit f` (line 3) starts another internal reaction that awakes the
`await f` in *trail-2* (line 5).
*Trail-2* terminates and the `emit f` resumes in *trail-1*.
*Trail-1* terminates and the `emit e` resumes in *trail-3*.
*Trail-3* terminates.
Finally, the `par/and` rejoins (all trails have terminated) and the program
terminates.

Organisms as abstractions
-------------------------

Céu uses an abstraction mechanism that reconciles data and control state into
the single concept of an *organism*.
Organisms provide an object-like interface (data state) as well as multiple
lines of execution (control state).

A class of organisms is composed of an *interface* and a single *execution
body*.
The interface exposes public variables, methods, and internal events, just like
objects.
The body can contain any valid code in Céu, which starts on the organism
instantiation and executes in parallel with the program.
Organism instantiation can be either [static](#variables) or [dynamic](#spawn).

The example below (in the right) blinks two LEDs in parallel with different
frequencies.
Each blinking LED is a static instance organism of the `Blink` class:

 1:  class Blink with
 2:      var int led;
 3:      var int freq;
 4:  do
 5:      loop do
 6:          _on(this.led);
 7:          await (this.freq)s;
 8:          _off(this.led);
 9:          await (this.freq/2)s;
10:      end
11:  end
12:
13:  var Blink b1 with
14:       this.led  = 0;
15:       this.freq = 2;
16:  end
17:
18:  var Blink b2 with
19:       this.led  = 1;
20:       this.freq = 4;
21:  end
22:
23:  await 1min;

 1:  var _Blink b1 with
 2:      this.led  = 0;
 3:      this.freq = 2;
 4:  end
 5:
 6:  var _Blink b2 with
 7:      this.led  = 1;
 8:      this.freq = 4;
 9:  end
10:
11:  par/or do
12:      // body of b1
13:      loop do
14:          _on(b1.led);
15:          await (b1.freq)s;
16:          _off(b1.led);
17:          await (b1.freq)s;
18:      end
19:      await FOREVER;
20:  with
21:      // body of b2
22:      loop do
23:          _on(b2.led);
24:          await (b2.freq)s;
25:          _off(b2.led);
26:          await (b2.freq)s;
27:      end
28:      await FOREVER;
29:  with
30:      await 1min;
31:  end

The `Blink` class (lines 1-11) exposes the `led` and `freq` fields, which
correspond to the LED port and blinking frequency to be configured for each
instance.
The application creates two instances, specifying the fields in the
constructors (lines 13-16 and 18-21).
A constructor starts the instance body to execute in parallel with the
application.
When reaching the `await 1min` (line 23), each instance already has its body
switching between `_on()` and `_off()` every `freq` milliseconds (lines 5-10).

The code in the left is semantically equivalent to the one in the right, which
expands the organisms bodies (lines 13-18 and 22-27) in a `par/or` with the
rest of the application (`await 1min`, in line 30).
Note the `await FOREVER` statements (lines 19 and 28) that avoid the organisms
bodies to terminate the `par/or`.
The `_Blink` type corresponds to a simple datatype without execution body
(i.e., conventional *structs* or *records* or objects).

See also [Organism declarations](#organisms), [Class and Interface
declarations](#classes-and-interfaces), and [Organisms
instantiation](#organism-instantiation).

------------------------------------------------------------------------------

Lexical rules
=============

Keywords
--------

Keywords in Céu are reserved names that cannot be used as identifiers (e.g.,
variable and class names):

        and             async           async/thread    atomic          await

        bool            break           byte            call            call/rec

        char            class           continue        data            do

        else            else/if         emit            end             escape

        event           every           f32             f64             false

        finalize        float           FOREVER         function        global

        if              in              input           input/output    int

        interface       interrupt       kill            loop            native

        native/pre      new             not             nothing         null

        or              outer           output          output/input    par

        par/and         par/or          pause/if        pool            pre

        return          s16             s32             s64             s8

        request         sizeof          spawn           sync            tag

        then            this            traverse        true            u16

        u32             u64             u8              uint            until

        var             void            watching        with            word

        @const          @hold           @nohold         @plain          @pure

        @rec            @safe

Identifiers
-----------

Céu uses identifiers to refer to *variables*, *internal events*, *external
events*,  *classes/interfaces*, *data types*, *data tags*, *fields*, and
*native symbols*.

```
ID       ::= <a-z, A-Z, 0-9, _>+
ID_var   ::= `_´ | ID           // [variables and internal events] beginning with a lowercase letter
ID_ext   ::= ID                 // [external events] all in uppercase, not beginning with a digit
ID_cls   ::= ID                 // [classes and interfaces] beginning with an uppercase letter
ID_data  ::= ID                 // [data types] beginning with an uppercase letter
ID_tag   ::= ID                 // [data tags] all in uppercase, not beginning with a digit
ID_field ::= ID                 // [fields] not beginning with a digit
ID_nat   ::= ID                 // [native symbols] beginning with an underscore
ID_type  ::= ( ID_nat | ID_cls  // [types]
             | <b>bool</b>  | <b>byte</b>  | <b>char</b>  | <b>f32</b>   | <b>f64</b>   |
             | <b>float</b> | <b>int</b>   | <b>s16</b>   | <b>s32</b>   | <b>s64</b>   |
             | <b>s8</b>    | <b>u16</b>   | <b>u32</b>   | <b>u64</b>   | <b>u8</b>    |
             | <b>uint</b>  | <b>void</b>  | <b>word</b> )
```

Class, interface, and data [declarations] create new [types] which can be used
as type identifiers.

Examples:

var int a;                    // "a" is a variable, "int" is a type
emit e;                       // "e" is an internal event
await E;                      // "E" is an external input event
var Sprite s;                 // "Sprite" is a class and a type
var List l;                   // "List" is a data type and a type
return list.CONS.head;        // "CONS" is a tag, "head" is a field
_printf("hello world!\n");    // "_printf" is a native symbol

Literals
--------

### Booleans

Boolean types have the values `true` and `false`.

### Integers

Integer values can be written in different bases and also as ASCII characters:

* Decimals are written *as is*.
* Octals are prefixed with <tt>0</tt>.
* Hexadecimals are prefixed with <tt>0x</tt>.
* ASCII characters and escape sequences are surrounded by apostrophes.
* `TODO: "1e10"`

Examples:

```
// all following are equal to the decimal 127
v = 127;
v = 0777;
v = 0x7F;

// newline ASCII character = decimal 10
c = '\n';
```

### Floats

`TODO (like C)`

### Null pointer

The `null` literal represents null [pointers](#pointer).

### Strings

A sequence of characters surrounded by `"` is converted into a *null-terminated
string*, just like in C:

Example:

```
_printf("Hello World!\n");
```

Comments
--------

Céu provides C-style comments.

Single-line comments begin with `//` and run to end of the line.

Multi-line comments use `/*` and `*/` as delimiters.
Multi-line comments can be nested by using a different number of `*` as delimiters.

Examples:

var int a;    // this is a single-line comment

/** comments a block that contains comments

var int a;
/* this is a nested multi-line comment
a = 1;
*/

**/

------------------------------------------------------------------------------

Types
=====

Céu is statically typed, requiring all variables and events to be declared before they are used.

A type is composed of an identifier with a sequence of optional modifiers:

Type ::= ID_type ( `&&´ | `&´ | `?´ | `[´ [NUM] `]´ )

A type identifier can be a [native identifier](#identifiers), a [class
identifier](#identifiers), a [data type identifier](#identifiers) or one of the
primitive types:

ID_type ::= ( ID_nat | ID_cls | ID_data
              bool  | byte  | char  | f32   | f64   |
              float | int   | s16   | s32   | s64   |
              s8    | u16   | u32   | u64   | u8    |
              uint  | void  | word )

Examples:

var u8 v;       // "v" is of 8-bit unsigned integer type
var _rect r;    // "r" is of external native type "rect"
var char&& buf; // "buf" is a pointer to a "char"
var Send s;     // "s" is an organism of class "Send"
var Tree t;     // "t" is a data of type "Tree"

Primitive types
---------------

Céu has the following primitive types:

    void               // void type
    word               // type with the size of platform dependent word
    bool               // boolean type
    char               // char type
    byte               // 1-byte type
    int      uint      // platform dependent signed and unsigned integer
    s8       u8        // signed and unsigned  8-bit integer
    s16      u16       // signed and unsigned 16-bit integer
    s32      u32       // signed and unsigned 32-bit integer
    s64      u64       // signed and unsigned 64-bit integer
    float              // platform dependent float
    f32      f64       // 32-bit and 64-bit floats

See also the [literals](#literals) for these types.

Native types
------------

Types defined externally in C can be prefixed by `_` to be used in Céu programs.

Example:

var _message_t msg;      // "message_t" is a C type defined in an external library

Native types support [annotations](#native-symbols) which provide additional
information to the compiler.

Class and Interface types
-------------------------

`TODO (brief description)`

See [Classes and Interfaces](#classes-and-interfaces).

Type modifiers
--------------

Types can be suffixed with the following modifiers: `&`, `&&`, `?`, and `[N]`.

### References

`TODO`

Céu supports two forms of references: *aliases* and *pointers*.

#### Alias

`TODO (like C++ references)`

#### Pointer

`TODO (like C)`

restrictions
    - across yielding statements

### Option

`TODO (like Maybe)`

### Dimension

`TODO (vectors, pools)`

One-dimensional vectors are declared by suffixing the variable type with the
vector length surrounded by `[` and `]`.
The first index of a vector is zero.

Example:

var int[2] v;       // declares a vector "v" of 2 integers

------------------------------------------------------------------------------

Statements
==========

Blocks
------

A block is a sequence of statements separated by semicolons (`;`):

```
Block ::= { Stmt `;´ }
```

*Note: statements terminated with the `end` keyword do not require a
terminating semicolon.*

A block creates a new scope for [variables](#variables), which are only visible
for statements inside the block.

Compound statements (e.g. [if-then-else](#conditional)) create new blocks and
can be nested for an arbitrary level.

### do-end

A block can be explicitly created with the `do-end` statement:

Do ::= do Block end

### Pre

TODO ("static code" appended in sequence to the beginning)

Pre ::= pre do Block end

Nothing
-------

`nothing` is a innocuous statement:

Nothing ::= nothing

Declarations
------------

### Variables

The syntax for the definition of variables is as follows:

DclVar ::= var Type ID_var [`=´ Assignment] { `,´ ID_var [`=´ Assignment] }

A variable has an associated [type](#types) and can be optionally initialized
(see [Assignments](#assignments)).

Variables are only visible inside the [block](#blocks) they are defined.

Examples:

var int a=0, b=3;   // declares and initializes integer variables "a" and "b"
var int[2] v;       // declares a vector "v" of size 2

#### Organisms

An organism is a variable whose type is the identifier of a [class
declaration](#classes-and-interfaces).
An optional constructor can initialize the organism fields:

DclOrg ::= var Type ID_var [ with
              Block
           end ]

Example:

class T with
    var int v;
do
    <body-of-T>
end
var T t with       // "t" is an organism of class "T"
    this.v = 0;    // whose field "v" is initialized to "0"
end

After the declaration, the body of an organism starts to execute in
[parallel](#parallel-compositions] with the rest of the application.
The table below shows the equivalent expansion of an organism declaration to a
[`par/or`](#paror) containing the class body:

<code-pre-declaration>
var T t with
    <code-constructor-of-t>
end;
<code-pos-declaration>

<code-pre-declaration>
par/or do
    <code-constructor-of-t>
    <code-body-of-class-T>
    await FOREVER;
with
    <code-pos-declaration>
end

Given that an organism is a variable, the block it is declared restricts its
lifetime.
In the expansion, the `par/or` makes the organism to go out of scope when
`<code-pos-declaration>` terminates.

`TODO (assumes code-pos-declaration closes the block exactly on the end)`

`TODO (vectors of organisms: copy the declaration N times)`

##### Constructors

Inside constructors the expression `this` refers to the new organism, while the
expression `outer` refers to the enclosing organism creating the new organism:

class U with
    var int v;
do
    ...
end

class T with
    var int v;
do
    var U u with
        this.v = outer.v;   // "this" is of class "U", "outer" is of class "T"
    end;
end

### Pools

A pool is a container for [dynamic instances of organisms](#spawn) and
[recursive data](#TODO) of the same type:

DclPool ::= pool Type ID_var [`=´ Assignment] { `,´ ID_var [`=´ Assignment] }

The type has to be a [class, interface, or data type identifier](#identifiers)
followed by a [dimension modifier](#dimension).
For pools of classes and recursive data types, the number inside the dimension
brackets represents the maximum number of instances supported by the pool.
For pools of interfaces, the number represents the maximum number of bytes for
all instances (as each instance may have a different size).

The number inside the vector modifier brackets is optional.
If not specified, the number of instances in the pool is unbounded and all
allocations go to the heap.
When specified, allocation goes to a static memory pool preallocated at compile
time.

Examples:

pool T[10]  ts;      // a pool of at most 10 instances of class "T"
pool T[]    ts;      // an unbounded pool of instances of class "T"
pool I[100] is;      // a pool of at most 100 bytes of instances of interface "I"
pool I[]    is;      // an unbounded pool of instances of interface "I"
pool D[100] ds;      // a pool of at most 100 instances of recursive data type "D"
pool D[]    ds;      // an unbounded pool of instances of recursive data type "D"

The lifetime of all instances inside a pool is restricted to the block it is
declared.
When a pool of organisms goes out of scope, all organism bodies are
automatically aborted.

See [Dynamic execution](#spawn) for organisms allocation.
See [TODO](#TODO) for recursive data allocation.

### Functions

`TODO (intro/prototype/implementation)`

/* internal functions */
DclFun ::= function [@rec] `(´ParList`)´ `=>´ Type ID_var
              [ `do´ Block `end´ ]

/* external functions */
DclFunExt ::= output [@rec] `(´ParList`)´ `=>´ Type ID_var ID_ext { `,´ ID_ext }
            | input  [@rec] `(´ParList`)´ `=>´ Type ID_var ID_ext { `,´ ID_ext }
                 [ `do´ Block `end´ ]

Return ::= return [Exp]

ParList ::= ParItem { `,´ ParItem }
ParItem ::= [@hold] Type [ID_var]

#### Internal functions

`TODO (like functions in any language)`

#### External functions

`TODO (more or less like dynamically loaded functions)`

##### return

`TODO (like return in any language)`

### Interrupt service routines

`TODO`

DclIsr ::= interrupt `[´ NUM `]´ [@rec]
              [ `do´ Block `end´ ]

### Events

See also [Event handling](#event-handling).

#### Internal events

Internal events have the same purpose of external events, but for
[communication within trails in a program](#internal-reactions).

The declaration of internal events is as follows:

DclInt ::= event (Type | `(´ TypeList `)´) ID_var { `,´ ID_var }

In contrast with external events, an internal event is for input and output at
the same time.

Internal events cannot be of a vector type.

*Note: <tt>void</tt> is a valid type for signal-only internal events.*

#### External events

External events are used as interfaces between programs and devices from the
real world:

* *input* events represent input devices, such as sensors, switches, etc.
* *output* events represent output devices, such as LEDs, motors, etc.

Being reactive, programs in Céu have input events as their sole entry points
through [await statements](#await-statements).

The declaration of input and output events is as follows:

DclExt ::= output (Type | `(´ TypeList `)´) ID_ext { `,´ ID_ext }
         | input  (Type | `(´ TypeList `)´) ID_ext { `,´ ID_ext }

TypeList ::= Type { `,´ Type }

Events communicate values between the environment and the application (and
vice-versa).
The declaration includes the [type](#types) of the value, which can be also a
list of types when the event communicates multiple values.

*Note: `void` is a valid type for signal-only events.*

The visibility of external events is always global, regardless of the block they are declared.

Examples:

input void A,B;      // "A" and "B" are input events carrying no values
output int MY_EVT;   // "MY_EVT" is an output event carrying integer values

The availability of external events depends on the platform in use.
Therefore, external declarations just make pre-existing events visible to a
program.

Refer to [Environment](#environment) for information about interfacing with
external events in the platform level.

##### External Requests

`TODO (emit + await)`

DclReq ::= output/input `[´ [Exp] `]´ `(´ParList`)´ `=>´ Type ID_ext { `,´ ID_ext }
         | input/output `[´ [Exp] `]´ `(´ParList`)´ `=>´ Type ID_ext { `,´ ID_ext }
            [ `do´ Block `end´ ]

### Classes and Interfaces

A `class` is a template for creating organisms.
It contains an *interface* and a *body* common to all instances of the class.
The interface exposes internal variables, events, and methods that other
organisms can manipulate directly.
The body specifies the behavior of the organism and executes when it is
instantiated.

An `interface` is a template for classes that shares the same
interface1.
The body and method implementations may vary among classes sharing the same
interface.

(1
*The term "interface" is overload with two possible meanings: the set of
members exposed by a class; and a template that defines a set of members that
classes can reuse.*)

The declaration of classes and interfaces is as follows:

DclCls ::= class ID_cls with
                Dcls    // interface
            do
                Block   // body
            end

DclIfc ::= interface ID_cls with
                Dcls    // interface
            end

Dcls ::= { (DclVar | DclInt | DclPool | DclFun | DclImp) `;´ }

DclImp ::= interface ID_cls { `,´ ID_cls }

`Dcls` is a sequence of variables, events, pools, and functions (methods)
declarations.
It can also refer to other interfaces through a `DclImp` clause, which copies
all declarations from the referred interfaces.

### Data Types

`TODO`

DclData ::= data ID_data with
                (Struct | Union)
            end

Struct ::= DclVar `;´ { DclVar `;´ }
Union  ::= DclTag { or DclTag }

DclVar ::= var Type ID_var { `,´ ID_var }
DclTag ::= tag ID_tag with
               DclVar `;´ { DclVar `;´ }
           end

### Native declarations

#### Native blocks

`TODO (native/pre)`

Native blocks define new types, variables, and functions in C:

Native ::= (native | native/pre) do
               <code_in_C>
           end

Example:

native do
    #include <assert.h>
    int inc (int i) {
        return i+1;
    }
end
_assert(_inc(0) == 1);

If the code in C contains the terminating `end` keyword of Céu, the `native`
block should be delimited with any matching comments to avoid confusing the
parser:

native do
    /*** c code ***/
    char str = "This `end` confuses the parser";
    /*** c code ***/
end

#### Native annotations

Native declarations provide additional information about external C symbols.
A declaration is an annotation followed by a list of symbols:

DclNat   ::= native [@pure|@const|@nohold|@plain] Nat_list
Nat_list  ::= (Nat_type|Nat_func|Nat_var) { `,` (Nat_type|Nat_func|Nat_var) }
Nat_type  ::= ID_nat `=´ NUM
Nat_func  ::= ID_nat `(´ `)´
Nat_var   ::= ID_nat

A type declaration may define its size in bytes to help the compiler organizing
memory.
A type of size `0` is an *opaque type* and cannot be instantiated as a variable
that is not a pointer.

Functions and variables are distinguished by the `()` that follows function declarations.

Native symbols can have the following annotations:

**@plain** states that the type is not a pointer to another type.
**@const** states that the symbol is a constant (e.g. a `#define`).
**@pure** states that the function has no side effects.
**@nohold** states that the function does not hold pointers passed as parameters.

The [static analysis](#static-analysis) of Céu relies on annotations.

Examples:

native _char=1, _FILE=0;              // "char" is a 1-byte type, while `FILE` is "opaque"
native @plain  _rect;                  // "rect" is not a pointer type
native @const  _NULL;                  // "NULL" is a constant
native @pure   _abs(), _pow();         // "abs" and "pow" are pure functions
native @nohold _fprintf(), _sprintf(); // functions receive pointers but do not hold references to them

### Deterministic annotations

A variable or function can be declared as `@safe` with a set of other functions
or variables:

DclDet ::= @safe ID with ID { `,´ ID }

Example:

native _p, _f1(), _f2();
@safe _f1 with _f2;
var int* p;
@safe p with _p;
par do
    _f1(...);    // `f1` is safe with `f2`
    *p = 1;      // `p`  is safe with `_p`
    ...
with
    _f2(...);    // `f2` is safe with `f1`
    *_p = 2;     // `_p` is safe with `p`
    ...
end

See also [Static analysis](#static-analysis).

Assignments
-----------

Céu supports many kinds of assignments:

Set ::= (Exp | `(´VarList`)´) `=´ Assignment

VarList ::= ID_var  { `,´ ID_var } `)´

Assignment ::= Exp
             | AssignableBlock
             | <await>
             | ( [ `(´ ] <emit-ext&gt
                       | <call-ext>
                       | <request-ext>
                 [ `)´ ] )
             | [ `new´ ] Data
             | <traverse-loop>
             | <traverse-rec>
             | Vector
             | <lua>
             | <do-org>
             | <spawn>
             | <thread>

The expression on the left side must be [assignable](#assignable).

TODO (Exp, VarList)

### Simple assignment

The simpler form of assignment uses [expressions](#expressions) as values.

Example:

var int a,b;
a = b + 1;

### Block assignment

A whole block can be used as an assignment value by escaping from it.
The following block statements can be used in assignments: [`do-end`](#do-end)
[`if-then-else`](#conditional), [`loop`](#loop), [`every`](#every), and
[`par`](#par):

AssignableBlock ::= <do-end> | <if-then-else> | <loop> | <every> | <par>

#### escape

An `escape` statement escapes the deepest block being assigned to a variable.
The expression following it is then assigned to the respective variable:

Escape ::= escape Exp

Every possible path inside the block must reach a `escape` statement whose
expression becomes the final value of the assignment.

Example:

a = loop do              // a=1, when "cond" is satisfied
        ...
        if cond then
            escape 1;    // "loop" is the deepest assignment block
        end
        ...
    end

Every program in Céu contains an implicit `do-end` surrounding it, assigning to
a special integer variable `$ret` holding the return value for the program
execution.

Therefore, a program such as

escape 1;

should read as

var int $ret =
    do
        escape 1;
    end;

### Await assignment

See [Await statements](#await-statements).

### Emit assignment

See [Emit statements](#emit-statements).

### Data assignment

`TODO`

Data ::= ID_data [`.´ ID_tag] `(´ List `)´
List ::= [ (Data|Exp) { `,´ (Data|Exp) } ]

### Traverse assignment

`TODO`

### Vector assignment

`TODO`

Vector ::= Item { `..´ Item }
Item   ::= Exp | `[´ [ExpList] `]´

### Lua assignment

`TODO`

### Do organism assignment

`TODO`

### Spawn assignment

See [Spawn](#spawn).

### Thread assignment

See [Threads](#threads).

Calls
-----

The syntax for function calls is as follows:

/* internal calls */
CallInt ::= [call|call/rec] Exp * `(´ [ExpList] `)´

/* external calls */
CallExt ::= (call+call/rec) ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)

ExpList = Exp { `,´ Exp }

### Internal calls

`TODO`

### External calls

`TODO`

Event handling
--------------

Events are the most fundamental concept of Céu, accounting for its reactive
nature.
Programs manipulate events through the `await` and `emit` statements.
An `await` halts the running trail until that event occurs.
An event occurrence is broadcast to all trails trails awaiting that event,
awaking them to resume execution.

Céu supports external and internal events.
External events are triggered by the [environment](#environment), while
internal events, by the `emit` statement.
See also [Synchronous execution model] for the differences between external and
internal reactions.

### Await statements

The `await` statement halts the running trail until the referred *wall-clock*
time, [input event](#external), or [internal event](#internal) occurs.

Await ::= ( await ID_ext |
            await Exp    |
            await (WCLOCKK|WCLOCKE)
          ) [ until Exp ]
       | await FOREVER

WCLOCKK ::= [NUM h] [NUM min] [NUM s] [NUM ms] [NUM us]
WCLOCKE ::= `(´ Exp `)´ (h|min|s|ms|us)

Examples:

await A;                  // awaits the input event `A`
await a;                  // awaits the internal event `a`

await 10min3s5ms100us;    // awaits the specified time
await (t)ms;              // awaits the current value of the variable `t` in milliseconds

await FOREVER;            // awaits forever

An `await` may evaluate to zero or more values which can be captured with the
optional assignment syntax.

The optional `until` clause tests an additional condition required to awake.
It can be understood as the expansion below:

loop do
    await <...>;
    if <Exp> then
        break;
    end
end

#### Await event

For await statements with [internal](#internal) or [external](#external)
events, the running trail awakes when the referred event is emitted.
The `await` evaluates to the type of the event.

input int E;
var int v = await E;

event (int,int*) e;
var int  v;
var int* ptr;
(v,ptr) = await e;

`TODO (awake rule for internal events, unless "every")`

#### Await time

For await statements with *wall-clock* time (i.e., time measured in minutes,
milliseconds, etc.), the running trail awakes when the referred time elapses.

A constant time is expressed with a sequence of value/unit-of-time pairs (see
`WCLOCKK` above).
An expression time is specified with an expression in parenthesis followed by a
single unit of time (see `WCLOCKE` above).

The `await` evaluates to the *residual delta time (dt)* (i.e.  elapsed time
*minus* requested time), measured in microseconds:

var int dt = await 30ms;    // if 31ms elapses, then dt=1000

*Note: `dt` is always greater than or equal to 0.*

#### Await organism

`TODO`

#### Await FOREVER

The `await FOREVER` halts the running trail forever.
It cannot be used in assignments, because it never evaluates to anything.

### Emit statements

The `emit` statement triggers the referred *wall-clock* time, [input
event](#external), or [internal event](#internal), awaking all trails waiting
for it.

Emit ::= emit Exp    [ `=>´ (Exp | `(´ [ExpList] `)´)
      |  emit ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)
      |  emit (WCLOCKK|WCLOCKE)

#### Emit event

Emit statements with [internal](#internal) or [external](#external) events
expect parameters that match the event type (unless the event is of type
`void`).

Examples:

output int E;
emit E => 1;

event (int,int) e;
emit e => (1,2);

External input events can only be emitted inside [asynchronous
blocks](#asynchronous-blocks).

The emission of internal events start new [internal
reactions](#internal-reactions).

`TODO (emit output evaluates to "int")`

#### Emit time

Emit statements with *wall-clock* time expect expressions with units of time,
as described in [Await time](#await-time).

Like input events, time can only be emitted inside [asynchronous
blocks](#asynchronous-blocks).

### Requests

`TODO (emit+await)`

Request ::= request ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)

Organism instantiation
----------------------

### Do organism

`TODO`

DoOrg ::= do ID_cls [with
              Constructor
          end]

### Spawn

The `spawn` statement creates instances of organisms dynamically:

Spawn ::= spawn ID_cls [in Exp] [with
              Constructor
          end]

TODO(option return)

The optional `in` clause allows the statement to specify in which
[pool](#pools) the organisms will live.
If absent, the organism is allocated on an implicit pool in the outermost block
of the class the allocation happens.

On allocation, the body of the organism starts to execute in parallel with the
rest of the application, just like [static organisms](#organisms).
The constructor clause is also the same as for [static
organisms](#constructors).

In contrast to static organisms, the lifetime of a dynamic instance is attached
to the scope of the pool and not to the scope of the `spawn` instantiation.
Furthermore, a dynamic organism is automatically deallocated when its execution
body terminates.

See [Static analysis](#organisms-references) for the restrictions on
manipulating pointers and references to organisms.

### Kill

`TODO`

kill * Exp * [ `=>´ Exp ]

Conditional
-----------

Conditional flow uses the `if-then-else` statement:

If ::= if Exp then
           Block
       { else/if Exp then
           Block }
       [ else
           Block ]
       end

The block following `then` executes if the condition expression after the `if`
evaluates to a non-zero value.
Otherwise, the same process holds each `else/if` alternative.
Finally, it they all fail, the block following the `else` executes.

Loop
----

A `loop` continuously executes its body block:

Loop ::= loop[`/´ Exp] [ ID_var [in Exp] ] do
             Block
         end

A `loop` terminates when it reaches a [`break`](#break) or its (optional)
[iterator](#iterators) terminates.

`TODO (hard limit)`

### break

A `break` escapes the innermost enclosing loop:

Break ::= break

Example:

loop do                   // loop 1
    ...
    loop do               // loop 2
        if <cond-1> then
            break;        // escapes loop 2
        end
        ...
    end
    ...
    if <cond-2> then
        break;            // escapes loop 1
    end
    ...
end

### continue

A `continue` restarts the innermost enclosing loop:

Continue ::= continue

Example:

loop do                   // loop 1
    ...
    loop do               // loop 2
        if <cond-1> then
            continue;        // restarts loop 2
        end
        ...
    end
    ...
    if <cond-2> then
        break;            // restarts loop 1
    end
    ...
end

A `continue` can only be used inside an [`if-then-else`](#conditional) with an
empty `else` branch and exactly one level deeper than the enclosing `loop`:

loop do
    par do    // makes the "continue" illegal
        if <cond> then
            continue;
        else  // makes the "continue" illegal
            ...
        end
    with
        ...
    end
end

### Iterators

A `loop` may specify an iterator that yields a new value on each loop
iteration.

#### Incremental index

For iterators in which `Exp` is empty or is of type `int`, `ID_var` is
incremented after each loop iteration.
`ID_var` is automatically declared read-only, with visibility restricted to the
loop body, and is initialized to zero.
The optional `Exp` limits the number of iterations, and is evaluated once
before the loop starts.

Example:

loop i in 10 do
    _printf("i = %d\n", i);     // prints "i = 0" up to "i = 9"
end

#### Pool instances

For iterators in which `Exp` evaluates to a pool of organisms, `ID_var`
evaluates to pointers to instances in the pool, one at a time, from the oldest
to the newest created.
`ID_var` is automatically declared read-only, with visibility restricted to the
loop body.

`TODO (example)`

### every

The `every` statement continuously awaits an event and executes its body:

Every ::= every (Var | `(´VarList`)´) in (WCLOCKK|WCLOCKE|ID_ext|Exp) do
              Block
          end

An `every` expands to a `loop` as illustrated below:

every <attr> in <event> do
    <block>
end

loop do
    <attr> = await <event>
    <block>
end

The body of an `every` cannot contain an `await`, ensuring that no occurrences
of `<event>` are ever missed.

`TODO (restrictions, escape/break)`

`TODO (exception to the rule for internal events)`

### Traverse

`TODO`

TraverseLoop ::= traverse ID_var in (`[´ Exp `]´ | Exp)
                    [ with Dcls end ]
                 do
                     Block
                 end
TraverseRec  ::= traverse['/' NUM] Exp
                     [ with Block end ]

Finalization
------------

The `finalize` statement postpones the execution of its body to happen when its
associated block goes out of scope:

Finalize ::= finalize
                 [Exp `=´ Assignment]
             with
                 Block
             end

The presence of the optional attribution clause determines which block to
associate with the `finalize`:

1. The enclosing block, if the attribution is absent.
2. The block of the variable being assigned, if the attribution is present.

Example:

input int A;
par/or do
    var _FILE* f;
    finalize
        f = _fopen("/tmp/test.txt");
    with
        _fclose(f);
    end
    every v in A do
        fwrite(&v, ..., f);
    end
with
    await 1s;
end

The program opens `f` and writes to it on every occurrence of `A`.
The writing trail is aborted after one second, but the `finalize` safely closes
the file, because it is associated to the block that declares `f`.

The [static analysis](#static-analysis) of Céu enforces the use of `finalize`
for unsafe attributions.

Parallel compositions
---------------------

The parallel statements `par/and`, `par/or`, and `par` split the running trail
in multiple others:

Pars ::= (par/and|par/or|par) do
               Block
          with
               Block
          { with
               Block }
           end

They differ only on how trails terminate (rejoin).

See [Synchronous execution model](#synchronous-execution-model) for a detailed
description of parallel execution.

### par/and

The `par/and` statement stands for *parallel-and* and rejoins when all trails
terminate:

### par/or

The `par/or` statement stands for *parallel-or* and rejoins when any of the
trails terminate:

### par

The `par` statement never rejoins and should be used when the trails in
parallel are supposed to run forever:

### watching

The `watching` statement aborts its body when its associated event occurs:

 Watching ::= watching [ (Var | `(´VarList`)´) in ] (WCLOCKK|WCLOCKE|ID_ext|Exp)
                 Block
             end

A `watching` expands to a `par/or` as illustrated below:

watching <...> in <event> do
    <block>
end

par/or do
    <...> await <event>
with
    <block>
end

`TODO (Var/VarList is implicitly declared)`

`TODO: strong abortion`

`TODO: see Await for supported events`

pause/if
--------

`TODO`

Pause ::= pause/if Exp do
              Block
          end

Asynchronous execution
----------------------

Asynchronous execution permit that programs execute time consuming computations
without interfering with the *synchronous side* of applications (i.e.,
everything, except asynchronous statements).

Async ::= (async | async/thread) [ `(´VarList`)´ ] do
              Block
          end

### Asynchronous blocks

Asynchronous blocks (`async`) are the simplest alternative for asynchronous
execution.

An `async` body can contain non-awaiting loops (*tight loops*), which are
[disallowed](#bounded) on the synchronous side to ensure that programs remain
reactive.

The optional list of variables copies values between the synchronous and
asynchronous scopes.
With the prefix `&`, the variable is passed by reference and can be altered
from inside the `async`.

The next example uses an `async` to execute a time-consuming computation,
keeping the synchronous side reactive.
In a parallel trail, the program awaits one second to kill the computation if it takes too long:

var int fat;
par/or do
    var int v = ...

    // calculates the factorial of v
    fat = async (v) do
        var int fat = 1;
        loop i in v do   // a tight loop
            // v varies from 0 to (v-1)
            fat = fat * (i+1);
        end
        return fat;
    end;
with
    await 1s;          // watchdog to kill the async if it takes too long
    fat = 0;
end
return fat;

An `async` has the following restrictions:

1. Only executes if there are no pending input events.
2. Yields control on every `loop` iteration on its body.
3. Cannot use parallel compositions.
4. Cannot nest other asyncs.
5. Cannot `await` events.
6. Cannot `emit` internal events.

#### Simulation

An `async` is allowed to trigger [input events](#emit-event) and the [passage
of time](#emit-time), providing a way to test programs in the language itself:

input int A;

// tests a program with a simulation in parallel
par do

    // original program
    var int v = await A;
    loop i do
        await 10ms;
        _printf("v = %d\n", v+i);
    end

with

    // input simulation
    async do
        emit A=>0;      // initial value for "v"
        emit 1s35ms;    // the loop executes 103 times
    end
    return 0;
end

Every time the `async` emits an event, it suspends (due to rule `1` of previous
section).
The example prints the `v = <v+i>` message exactly 103 times.

### Threads

`TODO(async/thread)`

#### Synchronous blocks

`TODO`

Sync ::= sync do
             Block
         end

#### Atomic blocks

`TODO(mutual exclusion isr and sync)`

Atomic ::= atomic do
             Block
         end

C statements
------------

`TODO`

C ::= `{´ <C code> `}´

Lua statements
--------------

`TODO`

Lua ::= `[´ {`=´} `[´
                       { <lua code> | `@´ Exp }
                   `]´ {`=´} `]´

------------------------------------------------------------------------------

Expressions
===========

The syntax for expressions in Céu is as follows:

Exp ::= Prim
        |  Exp or Exp
        |  Exp and Exp
        |  Exp (`!=´|`==´|`<=´|`<´|`>´|`>=´) Exp
        |  Exp `|´ Exp
        |  Exp `^´ Exp
        |  Exp `&´ Exp
        |  Exp (`<<´|`>>´) Exp
        |  Exp (`+´|`-´) Exp
        |  Exp (`*´|`/´|`%´) Exp
        |  (not|`+´|`-´|`~´|`*´|`&&´|`&´|`$$´|`$´) Exp
        |  `(´ Type `)´ Exp     /* same precedence as previous */
        |  Exp `[´ Exp `]´      /* same precedence for all following */
        |  Exp (`.´|`:´) (ID_field | ID_tag)
        |  Exp (`?´|`!´)
        |  Exp `(´ [ExpList] `)´ [finalize with Block end]

Prim ::= `(´ Exp `)´
        |  sizeof `(´ (Type|Exp) `)´
        |  ID_var | ID_nat
        |  null | NUM | String
        |  true | false
        |  global | this | outer
        |  (call | call/rec) Exp
        |  <c-stat&gt

*Note: assignments are not expressions in Céu.*

Primary
-------

`TODO: global, this, outer, ID_var, ID_nat, null, NUM, String, true, false,
call/call/rec/finalize, C, parens`

Arithmetic
----------

The arithmetic operators of Céu are

```
    +      -      %      *      /      +      -
```

which correspond to *addition*, *subtraction*, *modulo (remainder)*, *multiplication*, *division*, *unary-plus*, and *unary-minus*.

Relational
----------

The relational operators of Céu are

```
    ==      !=      >      <      >=      <=
```

which correspond to *equal-to*, *not-equal-to*, *greater-than*, *less-than*, *greater-than-or-equal-to*, and *less-than-or-equal-to*.

Relational expressions evaluate to 1 (*true*) or 0 (*false*).

Logical
-------

The logical operators of Céu are

    not      and      or

Bitwise
-------

The bitwise operators of Céu are

```
    ~      &      |      ^      <<      >>
```

which correspond to *not*, *and*, *or*, *xor*, *left-shift*, and *right-shift*.

Vector indexing
---------------

Céu uses square brackets to index [vectors](#Vectors):

```
Index ::= Exp `[´ Exp `]´
```

The expression on the left side is expected to evaluate to a vector.

Vector indexes start at zero.

References
----------

`TODO`

### Aliasing

`TODO`

```
Alias ::= `&´ Exp
```

The operand to `&` must be an [[#sec.exps.assignable|assignable
expression]].

### Pointer referencing and dereferencing
-----------------------------------------

`TODO`

The operator `&&` returns the address of its operand, while the
operator `*` dereferences its pointer operand.

```
Address ::= `&&´ Exp
Deref   ::= `*´ Exp
```

The operand to `&&` must be an [[#sec.exps.assignable|assignable
expression]].

Fields
------

`TODO (tags,fields)`

### Structs

The operators `.´ and `:´ access the fields of structs.

```
Dot   ::= Exp `.´ Exp
Colon ::= Exp `:´ Exp
```

The operator `.` expects a `struct` as its left operand, while the operator `:`
expects a reference to a `struct`.

Example:

native do
    typedef struct {
        int v;
    } mystruct;
end
var _mystruct s;
var _mystruct* p = &s;
s.v = 1;
p:v = 0;

*Note: `struct` must be declared in C, as Céu currently has no support for it.*

### Organisms

`TODO`

`TODO (index clash)`

Option
------

`TODO (?!)`

Type casting
------------

Céu uses parenthesis for type casting:

Cast ::= `(´ ID_type `)´

Sizeof
------

A `sizeof` expression returns the size of a type or expression, in bytes:

Sizeof ::= sizeof `(´ (Type|Exp) `)´

Precedence
----------

Céu follows the same precedence of C operators:

    /* lowest priority */

    or

    and

    !=    ==    <=    >=    <     >

    |

    ^

    &

    >>    <<

    +     -

    *     /     %

    not    +    -    ~    *    &&    &    $$    $    (Type)

    ()    []    :    .    ?    !

    /* highest priority */

Assignable expressions
----------------------

An assignable expression (also known as an *l-value*) can be a variable, vector index, pointer dereference, or struct access.
L-values are required in [[#sec.stmts.assignments|assignments]] and [[#sec.exps.pointers|references]].

Examples:

var int a;
a = 1;

var int[2] v;
v[0] = 1;

var int&& p;
*p = 1;

var _mystruct s;
s.v = 1;

var _mystruct&& ps;
ps:v = 1;

------------------------------------------------------------------------------

Static analysis
===============

`TODO (introduction)`

Types
-----

`TODO (weakly typed, like C)`

`TODO (index clash)`

Loops
-----

`TODO`

Finalization
------------

`TODO`

`TODO (index clash)`

Organisms references
--------------------

`TODO`

------------------------------------------------------------------------------

Environment
===========

As a reactive language, Céu depends on an external environment (the host
platform) to provide input and output events to programs.
The environment is responsible for sensing the world and notifying Céu about changes.
The actual events vary from environment to environment, as well as the
implementation for the notification mechanism (e.g. *polling* or
*interrupt-driven*).

The C API
---------

The final output of the compiler of Céu is a program in C that follows a
standard application programming interface.
The interface specifies some types, macros, and functions, which the
environment has to manipulate in order to guide the execution of the original
program in Céu.

The example below illustrates a possible `main` for a host platform:

```c
#include "_ceu_app.c"

int main (void)
{
    char mem[sizeof(CEU_Main)];
    tceu_app app;
        app.data = &mem;
    ceu_app_init(&app);

    while(app->isAlive) {
        ceu_sys_go(app, CEU_IN__ASYNC,  CEU_EVTP((void*)NULL));
        ceu_sys_go(app, CEU_IN__WCLOCK, CEU_EVTP(<how-much-time-since-previous-iteration>));
        if (occuring(CEU_IN_EVT1)) {
            ceu_sys_go(app, CEU_IN__EVT1, param1);
        }
        ...
        if (occuring(CEU_IN_EVTn)) {
            ceu_sys_go(app, CEU_IN__EVTn, paramN);
        }
    }
    return app->ret;
}

int occurring (int evt_id) {
    <platform dependent>
}
```

`tceu_app` is a type that represents an application in Céu.
The field `app.data` expects a pointer to the memory of the application, which
has to be previously declared.

`TODO`

### Types

`TODO`

`TODO (index clash)`

### Functions

`TODO`

`TODO (index clash)`

### Macros

`TODO`

### Constants and Defines

`TODO`

Compiler
--------

Céu provides a command line compiler that generates C code for a given input program.
The compiler is independent of the target platform.

The generated C output should be included in the main application, and is supposed to be integrated with the specific platform through the presented [[#sec.env.api|API]].

The command line options for the compiler are as follows:

    ./ceu <filename>              # Ceu input file, or `-` for stdin

        --output <filename>       # C output file (stdout)

        --defs-file <filename>    # define constants in a separate output file (no)

        --join (--no-join)        # join lines enclosed by /*{-{*/ and /*}-}*/ (join)

        --dfa (--no-dfa)          # perform DFA analysis (no-dfa)
        --dfa-viz (--no-dfa-viz)  # generate DFA graph (no-dfa-viz)

        --m4 (--no-m4)            # preprocess the input with `m4` (no-m4)
        --m4-args                 # preprocess the input with `m4` passing arguments in between `"` (no)

The values in parenthesis show the defaults for the options that are omitted.

------------------------------------------------------------------------------

Errors
======

Pointer attributions (11xx)
---------------------------

### 1101 : *wrong operator*

Use of the unsafe operator ":=" for non-pointer attributions.

Instead, use `=`.

Example:

var int v := 1;

>>> ERR [1101] : file.ceu : line 1 : wrong operator

### 1102 : *attribution does not require "finalize"*

Use of `finalize` for non-pointer attributions.

Instead, do not use `finalize`.

Example:

var int v;
finalize
    v = 1;
with
    <...>
end

>>> ERR [1102] : file.lua : line 3 : attribution does not require "finalize"

### 1103 : *wrong operator*

Use of the unsafe operator `:=` for constant pointer attributions.

Instead, use `=`.

Example:

var int ptr := null;

>>> ERR [1103] : file.ceu : line 1 : wrong operator

### 1104 : *attribution does not require "finalize"*

Use of `finalize` for constant pointer attributions.

Instead, do not use `finalize`.

Example:

var int ptr;
finalize
    ptr = null;
with
    <...>
end

>>> ERR [1104] : file.lua : line 3 : attribution does not require `finalize´

### 1105 : *destination pointer must be declared with the "[]" buffer modifier*

Use of normal pointer `*` to hold pointer to acquired resource.

Instead, use `[]`.

Example:

var int* ptr = _malloc();

>>> ERR [1105] : file.ceu : line 1 : destination pointer must be declared with the `[]´ buffer modifier

### 1106 : *parameter must be "hold"*

Omit `@hold` annotation for function parameter held in the class or global.

Instead, annotate the parameter declaration with `@hold`.

Examples:

class T with
    var void* ptr;
    function (void* v)=>void f;
do
    function (void* v)=>void f do
        ptr := v;
    end
end

>>> ERR [1106] : file.ceu : line 6 : parameter must be `hold´

/*****************************************************************************/

native do
    void* V;
end
function (void* v)=>void f do
    _V := v;
end

>>> ERR [1106] : file.ceu : line 5 : parameter must be `hold´

### 1107 : *pointer access across "await"*

Access to pointer across an `await` statement.
The pointed data may go out of scope between reactions to events.

Instead, don't do it. :)

(Or check if the pointer is better represented as a buffer pointer (`[]`).)

Examples:

event int* e;
var int* ptr = await e;
await e;     // while here, what "ptr" points may go out of scope
escape *ptr;

>>> ERR [1107] : file.ceu : line 4 : pointer access across `await´

/*****************************************************************************/

var int* ptr = <...>;
par/and do
    await 1s;   // while here, what "ptr" points may go out of scope
with
    event int* e;
    ptr = await e;
end
escape *ptr;

>>> ERR [1107] : file.ceu : line 8 : pointer access across `await´

### 1108 : *"finalize" inside constructor*

Use of `finalize` inside constructor.

Instead, move it to before the constructor or to inside the class.

Examples:

class T with
    var void* ptr;
do
    <...>
end

var T t with
    finalize
        this.ptr = _malloc(10);
    with
        _free(this.ptr);
    end
end;

>>> ERR [1008] : file.ceu : line 7 : `finalize´ inside constructor

/*****************************************************************************/

class T with
    var void* ptr;
do
    <...>
end

spawn T with
    finalize
        this.ptr = _malloc(10);
    with
        _free(this.ptr);
    end
end;

>>> ERR [1008] : file.ceu : line 7 : `finalize´ inside constructor

### 1109 : *call requires "finalize"*

Call missing `finalize` clause.

Call passes a pointer.
Function may hold the pointer indefinitely.
Pointed data goes out of scope and yields a dangling pointer.

Instead, `finalize` the call.

Example:

var char[255] buf;
_enqueue(buf);

>>> ERR [1009] : file.ceu : line 2 : call requires `finalize´'

### 1110 : *invalid "finalize"*

Call a function that does not require a `finalize`.

Instead, don't use it.

Example:

_f() finalize with
        <...>
     end;

>>> ERR [1010] : file.ceu : line 1 : invalid `finalize´

------------------------------------------------------------------------------

Syntax
======

Stmt ::= <empty-string>
      |  nothing
      |  escape Exp
      |  return [Exp]
      |  break
      |  continue

  /* Declarations */

      /* variables, organisms, pools, and internal events */
      | var Type ID_var [`=´ <Assignment>] { `,´ ID_var [`=´ <Assignment>] }
      | var Type ID_var with
            Block
        end
      | pool Type ID_var [`=´ <Assignment>] { `,´ ID_var [`=´ <Assignment>] }
      | event (Type | `(´ TypeList `)´) ID_var { `,´ ID_var }

      /* internal functions */
      | function [@rec] `(´ParList`)´ `=>´ Type ID_var
            [ `do´ Block `end´ ]

      /* external functions */
      | output [@rec] `(´ParList`)´ `=>´ Type ID_var ID_ext { `,´ ID_ext }
      | input  [@rec] `(´ParList`)´ `=>´ Type ID_var ID_ext { `,´ ID_ext }
            [ `do´ Block `end´ ]

      /* interrupts */
      | interrupt `[´ NUM `]´ [@rec]
            [ `do´ Block `end´ ]

      /* external events */
      | output (Type | `(´ TypeList `)´) ID_ext { `,´ ID_ext }
      | input  (Type | `(´ TypeList `)´) ID_ext { `,´ ID_ext }

      /* external requests */
      | output/input `[´ [Exp] `]´ `(´ParList`)´ `=>´ Type ID_ext { `,´ ID_ext }
      | input/output `[´ [Exp] `]´ `(´ParList`)´ `=>´ Type ID_ext { `,´ ID_ext }
            [ `do´ Block `end´ ]

      /* classes & interfaces */
      | class ID_cls with
            Dcls
        do
            Block
        end
      | interface ID_cls with
            Dcls
        end
          where
              Dcls   ::= { (<var> | <event-int> | <pool> | <function> | DclImp) `;´ }
              DclImp ::= interface ID_cls { `,´ ID_cls }

      /* data types */
      | data ID_data with
            (Struct | Union)
        end
          where
              Struct ::= DclVar `;´ { DclVar `;´ }
              Union  ::= DclTag { or DclTag }
                  where
                      DclVar ::= var Type ID_var { `,´ ID_var }
                      DclTag ::= tag ID_tag with
                                     DclVar `;´ { DclVar `;´ }
                                 end

      /* C integration */
      | native [@pure|@const|@nohold|@plain] Nat_list
          where
              Nat_list  ::= (Nat_type|Nat_func|Nat_var) { `,` (Nat_type|Nat_func|Nat_var) }
              Nat_type  ::= ID_nat `=´ NUM
              Nat_func  ::= ID_nat `(´ `)´
              Nat_var   ::= ID_nat
      | (native/pre | native) do
            <C code definitions>
        end

      /* deterministic annotations */
      | @safe ID with ID { `,´ ID }

  /* Assignments */

      | (Exp | `(´VarList`)´) `=´
          /* Assignment */
          ( Exp
          | AssignableBlock
          | <await>
          | ( [ `(´ ] <emit-ext&gt
                    | <call-ext>
                    | <request-ext>
              [ `)´ ] )
          | [ `new´ ] Data
          | <traverse-loop>
          | <traverse-rec>
          | Vector
          | <lua>
          | <do-org>
          | <spawn>
          | <thread>
          )
              where
                  Data ::= ID_data [`.´ ID_tag] `(´ List `)´
                  List ::= [ (Data|Exp) { `,´ (Data|Exp) } ]

                  Vector ::= Item { `..´ Item }
                  Item   ::= Exp | `[´ [ExpList] `]´

                  AssignableBlock ::= <do-end> | <if-then-else> | <loop> | <every> | <par>

  /* Function calls */

      /* internal calls */
      | [call|call/rec] Exp * `(´ [ExpList] `)´

      /* external calls */
      | (call+call/rec) ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)

  /* Event handling */

      /* internal/external await */
      | ( await ID_ext
        | await Exp
        | await (WCLOCKK|WCLOCKE)
        ) [ until Exp ]
      | await FOREVER

      /* internal/external emit */
      | emit Exp    [ `=>´ (Exp | `(´ [ExpList] `)´)
      | emit ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)
      | emit (WCLOCKK|WCLOCKE)

      /* external request */
      | request ID_ext [ `=>´ (Exp | `(´ [ExpList] `)´)

  /* Organism instantiation */

      /* do organism */
      | do ID_cls with
            Block
        end

      /* spawn */
      | spawn * ID_cls * [in Exp]
            [ with Block end ]

      /* kill */
      | kill * Exp * [ `=>´ Exp ]

  /* Flow control */

      /* explicit block */
      |  do Block end

      /* pre (top level) execution */
      | pre do
            Block
        end

      /* conditional */
      | if Exp then
            Block
        { else/if Exp then
            Block }
        [ else
            Block ]
        end

      /* loops */
      | loop[`/´ Exp] [ ID_var [in Exp] ] do
            Block
        end
      | every (Var | `(´VarList`)´) in (WCLOCKK|WCLOCKE|ID_ext|Exp) do
            Block
        end

      /* traverse */
      | traverse ID_var in (`[´ Exp `]´ | Exp)
            [ with Dcls end ]
            do
                Block
            end
      | traverse['/' NUM] Exp
            [ with Block end ]

      /* finalization */
      | finalize [<assignment>] with
            Block
        end

      /* parallel compositions */
      | (par/and|par/or|par) do
            Block
        with
            Block
        { with
            Block }
         end
      | watching [ (Var | `(´VarList`)´) in ] (WCLOCKK|WCLOCKE|ID_ext|Exp)
        do
            Block
        end

      /* pause */
      | pause/if Exp do
            Block
        end

      /* asynchronous execution */
      | (async | [async/thread]) [ `(´VarList`)´ ] do
            Block
        end

      /* synchronization */
      | sync do
            Block
        end
      | atomic do
            Block
        end

  /* C integration */

     | `{´ <C code> `}´

  /* Lua integration */

      | `[´ {`=´} `[´
            { <lua code> | `@´ Exp }
        `]´ {`=´} `]´

/* Block */

Block ::= { Stmt `;´ }

/* Identifiers */

ID       ::= <a-z, A-Z, 0-9, _> +
ID_var   ::= `_´ | ID    // beginning with a lowercase letter
ID_ext   ::= ID          // all in uppercase, not beginning with a digit
ID_cls   ::= ID          // beginning with an uppercase letter
ID_data  ::= ID          // beginning with an uppercase letter
ID_tag   ::= ID          // all in uppercase, not beginning with a digit
ID_field ::= ID          // not beginning with a digit
ID_nat   ::= ID          // beginning with an underscore
ID_type  ::= ( ID_nat | ID_cls | ID_data
             | bool  | byte  | char  | f32   | f64   |
             | float | int   | s16   | s32   | s64   |
             | s8    | u16   | u32   | u64   | u8    |
             | uint  | void  | word )

/* Types */

Type ::= ID_type ( `&&´ | `&´ | `?´ | `[´ [NUM] `]´ )

/* Lists */

TypeList ::= Type    { `,´ Type    }
ExpList  ::= Exp     { `,´ Exp     }
VarList  ::= ID_var  { `,´ ID_var  }
ParList  ::= ParItem { `,´ ParItem }
                where
                    ParItem ::= [@hold] Type [ID_var]

/* Wall-clock values */

WCLOCKK ::= [NUM h] [NUM min] [NUM s] [NUM ms] [NUM us]
WCLOCKE ::= `(´ Exp `)´ (h|min|s|ms|us)

/* Expressions */

Exp ::= Prim
        |  (`$$´|`$´) Exp
        |  Exp (`?´|`!´)
        |  Exp `(´ [ExpList] `)´ [finalize with Block end]

Prim ::= `(´ Exp `)´
        |  ID_var | ID_nat
        |  null | NUM | String
        |  true | false
        |  (call | call/rec) Exp
        |  <c-code&gt

/* Operator precedence */

    /* lowest priority */
    or
    and
    !=    ==    <=    >=    <     >
    |
    ^
    &
    >>    <<
    +     -
    *     /     %
    not    +    -    ~    *    &&    &    $$    $    (Type)
    ()    []    :    .    ?    !
    /* highest priority */

/* Other */

    // single-line comment

    /** nested
        /* multi-line */
        comments **/

    # preprocessor directive

------------------------------------------------------------------------------

License
=======

Céu is distributed under the MIT license reproduced below:

```
 Copyright (C) 2012 Francisco Sant'Anna

 Permission is hereby granted, free of charge, to any person obtaining a copy of
 this software and associated documentation files (the "Software"), to deal in
 the Software without restriction, including without limitation the rights to
 use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
 of the Software, and to permit persons to whom the Software is furnished to do
 so, subject to the following conditions:

 The above copyright notice and this permission notice shall be included in all
 copies or substantial portions of the Software.

 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
```

redpajama_set_name: RedPajamaGithub


Ordering Celine Dion Tickets is simple. For online ordering, click on any of the 'Tickets' icons below. To order over the phone, please call us at +1-404-467-0227. We are dedicated to providing you with premium seats for all Celine Dion events. We are your number one ticket broker for all Celine Dion Tickets and all Celine Dion Tickets worldwide.
Do you have cheap Celine Dion Tickets?
Empire Tickets has cheap Celine Dion tickets, premium Celine Dion tickets and everything in between. Use the interactive venue map to filter seats for the number of tickets needed in your price range to find the perfect seats! Empire Tickets is dedicated to providing you with the best seats at the best price anywhere online.


The first generation of the Futronic GMDSS was launched in 1995 and has faithfully served thousands of users worldwide up until today. As a successor to the Futronic MKI, Danphone has developed the Futronic MKII - the only test box on the market capable of multiple test functions.
The Futronic MKII contains all you need to perform a complete radio survey - all gathered in one small box. The test box has a user-friendly interface and is easy to use. MKII enables testing of all communication and safety devices required onboard vessels.


text:
Posts Tagged ' NYC '
How a Rooftop Meadow of Bees and Butterflies Shows N.Y.C.'s Future — The New York Times
For some species, scientists say, cities can be more hospitable than rural and suburban areas, because fewer lawns and farms mean fewer pesticides.
rooftop meadow
A Longhouse Birdhouse: BRAZENHEAD BOOKS ~
Source: A Longhouse Birdhouse: BRAZENHEAD BOOKS ~
brazenhead books
New York City – Brooklyn Bridge Direct Action – Extinction Rebellion (April 17th) – YouTube
Turning into the Night | FOP
image FOP 002018, from a LinkNYC station at Madison Avenue and 53rd Street
Source: Turning into the Night | FOP
photic habitat
New York City's 30 Most Iconic Dishes
Tuna Ribbons at Jean-Georges
Photo: Jean-Georges
All of them are worth trying once, if you want a taste of what makes this the most exciting dining city in the world.
Source: New York City's 30 Most Iconic Dishes
iconic dishes
Tuna Ribbons
UNKNOWN AND UNFRAMED……DISCOVERED BY JED
Details and additional images please contact: info@marion-harris.com 212.348.9688
Available for the first time ever, a selection of the photographic offshoots and out-takes discovered by JED will be for sale at The Outsider Art Fair opening on January 21st at The Metropolitan Pavilion, 125 West 18th Street in New York City. Presented by Marion Harris, an exhibitor since the fair's inception 23 years ago, the work is a new addition to the Outsider field.
A variation on the genre of vernacular or "found" photographs, JED's images have been retrieved(with permission) after being deliberately discarded by their original makers over the last decade.
Inspired by the concept of "The Artist's Struggle", these abandoned photographic images and test strips are presented out of context exemplifying the historical search for the perfect photograph.
JED is the fictitious persona of a university professor and photographer whose work has been exhibited internationally and is in private and museum collections — a background that gives theviewer and collector an unusual insight into the authority behind the photographic edit.
It is, literally, the story as seen from the outside. The process of selection, curation and editing is a visual narrative told by JED.
First shown at Lyman Allyn Art Museum in Connecticut in 2008, JED's intent is to encourage a dialogue comparing the value of work by professional and untrained photographers.
Marion Harris
The Outsider Art Fair
Jonas Mekas – Screen Shot from On Luigi Porto from Mekas Diaries, Notes and Sketches
Jonas Mekas at A Longhouse Birdhouse
It's all great but the video from which this screen shot derived is very beautiful with music, film, and poetry. – DF

redpajama_set_name: RedPajamaCommonCrawl


We spent a combined 53 years in public schools. It was our life's calling.
We worked our way up from teachers to principals to district administrators. So how on earth could we pack up our book bags and leave mid-career to start anew in a private school?
Every educator dreams of positively impacting student lives. But not every educator feels they can. Not because they lack the skill, but because something above us obstructs and impedes our efforts.
As teachers, we weren't empowered to decide the curriculum or testing for our kids. As principals, we couldn't hire the teachers who were always best for our students. As district administrators, we made decisions for the entire county, without facing the needs of individual schools or students.
Now, at an independent private school, we have ownership of our ideas and decisions. We can make immediate changes as needed, focus on the whole student and identify ways to serve his or her unique needs.
We approached that freedom timidly at first due to our experience of bureaucracy and red tape. We often sought permission from the executive pastor of Victory Church anticipating a "no." Instead, he encouraged us to think out of the box.
In Florida, thanks to school choice, more and more educators now have the ability to do what we did.
Florida now has 300,000 students in charter schools, and 140,000 students using state-supported scholarships to attend private schools. Students benefit from these options, including 301 at Victory Christian who use the Florida Tax Credit Scholarship for lower-income students. But so do thousands of educators who serve them.
At VCA, we know our approach is leading to academic success.
We've used our flexibility to hire teachers who are in sync with our mission and culture; to use the testing we think is best; even adjust curriculum where needed to increase the rigor.
For example, we switched to a growth-model test called the Measures of Academic Progress (MAP) in place of a one-time snapshot at the end of the year.
It allows us to test the learning gains of students three times per year. Unlike most standardized tests, including the Florida Standards Assessments, we get the results in 24 hours, not in the middle of the summer where it does little to inform teachers, students and parents. The Office of Student Learning at Step Up For Students provided invaluable support by training our staff and teachers to analyze and utilize the data. Now, the data is a driving force in decision-making.
Sitting down with our teachers, we're now able to drill down and locate specific learning gaps for individual students. Teachers, in turn, prescribe customized solutions. Lower-scoring students can be provided extra tutoring or summer school; high-scoring students can be promoted to more difficult material. Finding ways to differentiate is key to increasing student learning.
When MAP shined a giant spotlight on our math deficiencies, we researched math programs across the nation and replaced curriculum with Singapore Math at the recommendation of one of our experienced teachers. The key to a successful implementation is professional development, support and modeling. It worked! Last year, 79 percent of our lower-income scholarship students achieved a year's worth of growth, or more, in math, compared to about 55 percent nationally.
We never thought we'd leave public education. In a way, we never did. VCA has a similar demographic to Polk County Schools. We hire certified teachers. We're accredited by AdvancED.
But in other ways, VCA is different. It's special because we have the opportunity to use our educational experience, and the privilege to spiritually influence the lives of our students.
Over the past seven years, we've been blessed to see VCA grow from 260 to 560 students. We're still on a mission to positively impact the students in our community. All that's changed is the location.
Karla Collins is Head of School of Victory Christian Academy in Lakeland. Mark Thomas is the principal.


text:
Capitol Police Chief Submits Resignation Letter (Video) (Updated)
Dine has been under scrutiny. (Bill Clark/CQ Roll Call File Photo)
By Bridget Bowman and Emma Dumain
Posted April 10, 2015 at 12:41pm
| U.S. Capitol Police Chief Kim C. Dine has submitted a letter of resignation to the Capitol Police Board, multiple sources with direct knowledge of the situation confirmed to CQ Roll Call.
It is not currently known whether the letter has or will be accepted by the three-member board, made up of the House and Senate sergeants-at-arms and the Architect of the Capitol. Multiple attempts to secure a comment from Dine were unsuccessful.
However, Dine sent a message to Capitol Police employees late in the afternoon on April 10 that referred to news of his resignation letter, but did not directly refer to the letter:
"You may have become aware of reporting today that discusses my status as Chief of the U.S. Capitol Police. I would like to assure you that as your Chief, you have my full support as we continue to work together as a team that is focused on ensuring our success as we fulfill our critical mission. Our complex and inherently dangerous job is coupled with challenges that I have personally witnessed many of you expertly manage on a daily basis. Our continued ability to function as a Department is coupled with our abilities as a team. As your Chief, I am immensely appreciative of the work that you do on a daily basis. I have the highest level of confidence in all of our sworn and civilian personnel, and as your Chief, personally reaffirm my continued commitment to this Department."
Dine's stated intent to leave the agency comes at a moment when frustrations have come to a head, not just from rank-and-file officers but from the Capitol Police Board, too. The board made the decision to hire the former police chief from Frederick, Md., in December 2012, confident he could restore trust and accountability in the ranks after long-simmering discontent with Dine's immediate predecessors in the top brass.
On Friday evening, the chairman of the Capitol Police Board signaled the board would continue to work with Dine, but did not indicate whether the board has or will accept his letter of resignation.
"The United States Capitol Police Board continues to work with Chief Dine to ensure the success of the United States Capitol Police," Senate Sergeant-at-Arms Frank J. Larkin said in a statement to CQ Roll Call.
The chief's letter of resignation also comes amid reports of conflict within the department, which employs 1,775 sworn officers and 370 civilians. A recent CQ Roll Call report detailed growing frustration among rank-and-file officers regarding alleged policies passed down from department brass that officers should not participate in "low value" stops around the Capitol campus. The officers said the top priority was combating terrorist threats against the Capitol and lawmakers, with day-to-day policing taking a backseat.
Lawmakers questioned Dine about officer morale at a recent House Legislative Branch Appropriations Subcommittee hearing, following the reports. Dine has also been under scrutiny for the handling of a car chase the night of the State of the Union, which ended without an arrest despite the fact that the suspect was driving without a license . Members of Congress also grilled Dine after the October 2013 fatal shooting of Miriam Carey, as well as the decision to call back officers from the September 2013 Navy Yard shooting .
Despite the recent concerns about Dine's leadership, he did receive support from some lawmakers, including Senate Minority Leader Harry Reid, D-Nev., a former Capitol Police officer himself. "I'm for a strong Capitol Police," Reid said on March 3. "We need to give them more resources, rather than less."
succeedingdescribed
The Capitol Police Board opted to bring a chief from outside the USCP as the department was experiencing internal conflict over policies. He brought nearly 40 years of law enforcement experience to the Capitol Police, working for the Metropolitan Police Department of Washington, D.C., and leading the Frederick, Md., department.
"We'll definitely focus on building bridges and communication with all the stakeholders," Dine said in 2012 when the Capitol Police Board announced its decision to hire the law enforcement veteran. "That's just a good way of doing business."
Capitol Police Chief's Leadership Questioned
Social Media Policy Stirs Up More Trouble Within Capitol Police Ranks
Capitol Police Chief's Relationship With Union Hits New Low
Officer Morale a Hot Topic for Capitol Police at Appropriations Hearing
Driver in SOTU Police Chase Had No License, Police Say
Driver Arrested in SOTU Car Chase
Capitol Police Ordered Not to Arrest Driver in SOTU Car Chase
Immigration Protests in Capitol Offices Strain Police
Capitol Police Drug Bust Goes Bust
The 114th: CQ Roll Call's Guide to the New Congress
Get breaking news alerts and more from Roll Call in your inbox or on your iPhone.


"I think we should teach radio to fall and get up again." Dennis Laupman, CCO at Pluxbox, says that radio needs to grow, in accordance with the changes in media consumption. Community is key and the MARCONI platform can deliver the added value.
As an Innovation Manager at IN2, Alexandru Stan is constantly on the lookout for innovating and customer-oriented solutions to manage, access and publish content. In that perspective, MARCONI enhances the radio experience for both listeners and radio makers. In Alexandru's words: "Building the digital communication mechanisms to allow listeners and radio makers to come closer together and interact with one another can be very impactful."
Watch our first teaser and join MARCONI!
Have a look at our new project video and join our project's open pilot and platform! For more updates, subscribe to our newsletter.


We used this to quickly determine where a specific session was spending its time. This simply creates associative arrays for events, the time waited, and the total number of waits for that event, all at a specific point in time. The script then sleeps a user specified number of seconds, then loads a second set of associative arrays with similar data, only at the then current point in time.
Finally, it does the math for each event and prints the number of seconds spent on each event for the period of time specified, as well as the average number of milliseconds waited for each event in that session.
For example, below we can see the session is spending most of its time on single block I/O, but the average response time is reasonable at 7.2 milliseconds.


text:
KPMG's path to purpose
In this HBR article, KPMG describes the process it took to become purpose-driven and the tangible benefits it experienced
How an Accounting Firm Convinced Its Employees They Could Change the World
by Bruce N. Pfau
It's a fabled story about a janitor's exchange with President Kennedy during the early days of NASA: "What do you do?" the president supposedly asked the man with a broom during a visit to Cape Canaveral. "Well, Mr. President, I'm helping to put a man on the moon."
This meeting may not have actually taken place. But there's a good reason it's one of the most commonly-repeated management anecdotes: it illustrates the idea that a workforce motivated by a strong sense of higher purpose is essential to engagement. A survey by Calling Brands found that working for an organization with a clearly defined purpose is second only to pay and benefits in importance for employees, and ranks ahead of promotion opportunities, job responsibilities, and work culture. Two-thirds said a higher purpose would motivate them to go the extra mile in their jobs. A similar study by Net Impact showed that almost half of today's workforce would take a 15% pay cut to work for an organization with an inspiring purpose.
Convinced that today's workforce wants more than what they can see in their paychecks, our firm recently launched an initiative aimed at inspiring our already high-morale workforce reach new levels of engagement by reframing and elevating the meaning and purpose of their work. The results have exceeded our expectations. Our partners and employees have flooded us with stories, our morale scores have soared, and turnover has plummeted. Perhaps coincidentally, the firm also enjoyed one of its best financial years in recent memory—ranking as the fastest growing of the Big Four public accounting firms.
First, our firm needed to articulate our higher purpose. Extensive research, including hundreds of interviews, resulted in a new purpose statement: Inspire Confidence. Empower Change. But we knew we needed to do more than simply announce our purpose and expect it to take hold. We needed employees to experience it for themselves.
So, last year, we embarked on an initiative to build a stronger emotional connection to the firm and to have our people look at their work from a different perspective. It started with a simple question, "What do you do at KPMG?" and a video that answered: "We Shape History!"
The video highlighted dramatic, largely forgotten stories about KPMG's role in historic events: how we managed the Lend-Lease Act to help defeat Nazi Germany; resolved conflicting financial claims to lay the groundwork for the release of the U.S. hostages in Iran in 1981; and certified the election of Nelson Mandela in South Africa in 1994.
We created vivid posters like "We Champion Democracy" that celebrated the difference our people make on behalf of clients, communities, and society, and displayed them prominently in our offices. We reframed their roles, encouraging them to see themselves not simply as professionals executing audits, for example, but as members of a profession that helps millions of American families make better informed decisions about investing their life savings.
Most importantly, we recognized that just telling people from the top down about their higher purpose would not succeed. We encouraged everyone—from our interns to our Chairman—to share their own stories about how their work is making a difference.
To help, we developed an application that enabled our people to create and share digital posters modeled after the corporate posters that we created. Calling it the 10,000 Stories Challenge, we asked our 27,000 partners and employees in June to develop posters, as individuals or teams. We offered an incentive of two extra paid days off at the end of the year if we met the 10,000 stories goal by Thanksgiving.
One of the first posters created by KPMG to launch its higher purpose initiative (left) and two examples of the more than 42,000 purpose stories shared by employees. Courtesy of KPMG
Instead, we surpassed the goal before the Fourth of July. Soon, it became clear that the incentive wasn't the primary motivator — we received thousands more stories even after we announced the extra days off were assured. In a startling display of our people's pent up appetite to express the meaning of their work, by Thanksgiving we had received 42,000 stories.
On our annual partner survey, 90% reported that the higher purpose initiatives increased people's pride in KPMG. Scores on our employee engagement survey rose to record levels as well. Less than six months into our Purpose initiative 85% of employees agreed that KPMG is a great place to work, up slightly from 82% a year earlier; after a year scores on this same question rose to 89%. Additionally, 60% said our purpose initiative strengthened their pride in KPMG and our work. This improvement in morale also resulted in KPMG surging 17 spots on FORTUNE magazine's annual 100 Best Companies to Work For list, making us the number one-ranked Big Four firm for the first time in our history.
In that same survey, 76% of our employees said their "job had special meaning (and was not just a job)," six points higher than the average of our Big Four counterparts and a four-point jump year over year.
Some of our most interesting findings came from comparing survey scores of employees who said their managers discuss higher purpose with the scores of employees whose leaders don't. While correlational and not necessarily causative, we found a strong association between leaders who talk about the positive societal impact of their teams' work and a variety of positive human resources and business indicators.
As the chart above shows, among employees who told us their leaders discuss higher purpose, 94% said KPMG is a great place to work, and 94% said they are proud to work for KPMG. But among those whose leaders don't discuss purpose, the corresponding results dropped to 66% and 68%. This group also reported they are three times more likely to think about looking for another job than those whose leaders do talk about purpose. Not surprisingly, year-to-date actual turnover of these two groups is dramatically different, 9.1% vs 5.6% respectively. What's more, employees whose leaders communicated about purpose were far more motivated to strive for continuous improvement and high performance than colleagues whose leaders failed to discuss this important topic.
These big differences show up across generations of employees, regardless of whether someone is a Millennial or Baby Boomer. Moreover, relative to their representation in our workforce, older employees (those over 40) had proportionately somewhat higher participation in our 10,000 Stories Challenge than younger employees—suggesting that with all we hear about the difference in career attitudes among Millennials, Gen Xers and Baby Boomers, and the desire to recognize and express the higher purpose in one's work, seems to cut across generational boundaries.
While our higher purpose initiatives have succeeded beyond our most optimistic expectations, they have not been free of challenges, missteps and unanticipated issues. Below are some key stumbling blocks and how we addressed them.
Overcoming an academic focus. At the start of our efforts we probably spent more time than necessary focused on the academic, philosophical, and theoretical elements of higher purpose. Perhaps because of our profession's natural predilection for relying on clearly documented rules and definitions, we spent months considering the distinctions between purpose, vision, mission, ethos, and culture. And while this probably served a constructive function for the core project team, it seemed to either bore or confuse the very leaders, partners and employees we were attempting to engage.
We soon realized that our objective was not to edify people on the structure and objectives of national anthems; rather, it was to fill them with the pride, optimism and commitment that results from hearing the national anthem. From that point on, we eschewed the didactic and focused on creating an emotional connection with our people by showing them, and having them show us, why their work mattered.
Breaking through the message clutter. Like many large organizations, KPMG is challenged with information and message overload. So we were determined to make our purpose messaging both noticeable and memorable, engaging a third-party creative and communications agency. While we were ultimately successful, it was a heavy lift to convince our senior leadership team—which has always been skeptical of the return on investment of external advertising—to invest in a seven-figure communications campaign.
Overcoming risk aversion and hyper-conservatism. By training, policy and, some would say, temperament, a significant portion of our partners and employees tend to be cautious, precise and circumspect in their language and judgments. Sweeping statements that lack adequate proof points or qualifying explanations are almost reflexively met with professional skepticism. In this context, dramatic headlines like "We Shape History" or "We Champion Democracy," at first made some of our leaders uncomfortable. Fortunately, these concerns dissipated in the early stages of the initiative once they saw how positively our people responded to the powerful media we created and how enthusiastically they participated in creating their own dramatic declarations of purpose.
Exacerbating morale problems in certain groups. We noted earlier that employees whose leaders spoke about higher purpose were more engaged, motivated, and committed than those with leaders who failed to do so. Moreover, the employees with purpose-driven leaders showed improvement in their engagement levels in the year after we began our firm-wide purpose initiatives. By contrast, employees whose leaders did not talk about purpose actually saw a significant (6-11 percentage point) downturn in key engagement indicators.
At first, this finding seemed counterintuitive (i.e., even if this group is not as engaged as their counterparts, shouldn't the firm-wide messaging have at minimum improved their levels of engagement?) But upon more thought, we believe the downturn in morale may have resulted from the increased cynicism engendered by the perception of leadership hypocrisy (in other words, "Leadership tells me we are purpose-driven, but my boss never says a word about it.").
The fact that some of our leaders aren't yet talking about higher purpose represents a huge opportunity to increase engagement levels even further. We're now incorporating purpose storytelling training into our leadership development programs and helping participants develop compelling narratives and move past any reluctance to self-disclose. In other words, we're helping them to speak to people's hearts as well as their minds.
One graduate of this training brought 1,500 interns to their feet after she spoke to their hearts about her own higher purpose. She concluded by recounting the parable of three bricklayers who were rebuilding a church after it had been damaged by fire.
The construction architect observed the three workers on a scaffold, and asked "What are you doing?" to which the first bricklayer replied, "I'm laying bricks." The second responded, "I'm repairing a wall." But the third replied, "I'm building a cathedral to The Almighty."
"So, " our partner asked the crowd, "Do you want to be bricklayers or cathedral builders?" After her presentation, a crowd of enthusiastic interns surrounded her and more than a hundred emails followed, all with the same clarion message: "I want to be a cathedral builder."
We've learned many lessons in the course of our Higher Purpose initiative, but none greater than recognizing the extent of the workforce's pent-up appetite to build cathedrals—or fight terrorism, or protect life savings, or champion democracy—rather than simply lay bricks.
Ultimately, unleashing the untapped power of people inspired by a sense of purpose has not only heightened employee engagement, satisfaction and loyalty, but driven our employees to strive for peak performance as well.
Bruce N. Pfau, Ph.D., a partner at KPMG LLP, served as its Vice Chair of Human Resources & Communication from 2004 to 2016 and now advises the firm's C-suite clients on HR strategy and organization transformation.
Episode 4 of the Purpose Project: How decisions are...
Episode 5 of the Purpose Project: How Purpose accelerates...