Doppl is a new programming language that aims providing a natural syntax for implementing parallel algorithms, designing data structures for shared memory applications and automated message passing among multiple tasks. The name is an abbreviation of `data oriented parallel programming language`.

1. DOPPL
Data Oriented Parallel Programming Language
Development Diary
Iteration #9
Covered Concepts:
States in Detail, State Transition Operators
Diego PERINI
Department of Computer Engineering
Istanbul Technical University, Turkey
2013-09-15
1

2. Abstract
This paper stands for Doppl language development iteration #9. In this paper, the meaning
of "state" as a Doppl entity will be explained in detail. State transition operators and common usage
scenarios of states will be introduced. Conditional, unconditional and synchronized branching will be
demonstrated with examples.
1. Rationale
Current status of Doppl lacks proper language constructs to achieve branching in a single task as
well as declare synchronization points for a concurrently running task group. The way Doppl ecosystem
handles looping, synchronization and branching gave birth the idea of states, a kind of pipeline system to
create work breakdown structures.
2. States
A state is a special marker in a task body which can be used to jump to another instruction.
The word state in Doppl has nothing to do with application context as it can easily be seen that each
instruction in a state body is able to change it freely. Doppl tasks which belong to same task group are
able to wait each other using these markers.
A state is declared by typing a name followed by a colon and curly braces block.
init: This field is a language reserved state name and declares the initial state for its task. Any
branching for a newly spawned task is decided in this state block. There is no way for a task to bypass this
state. Initial state name must end with a colon ':' character like any other state declaration. (Iteration #1)
Below is an example pseudo program which loads some data to memory. It then computes some
calculations on the data to output some graphics to the screen.
#States explained
task(10) States {
#some members here
#Init task, must be declared in every task body
init: {
#init state used it to initialize tasks
#branch to load
}
flush_and_load: {
#load data to memory
#branch to process
}
2

3. process: {
#calculate some extra data for render
#wait until each task is ready to branch to render
}
render: {
#render only once using previously calculated data
#branch to process to create an infinite render loop
}
}
Each state is obligated to provide at least one state transition expression or a finish clause at the
last line of their block. States that lack such expressions imply a finish operation at the end of their
state block.
finish clause is a blocking synchronization expression that when each task of the same task
group meet at finish, the whole group halts simultaneously.
3. State Transition Operators
There are two operators to jump between states. They behave almost the same with the exception
of one's implying a task barrier line.
Non blocking transition: Operator keyword is '-->' without single quotes. Any task executing a
non blocking transition directly jumps to the state specified without waiting other tasks in the task group
it belongs.
Blocking transition: Operator keyword is '->' without single quotes. Any task executing a
blocking transition is obligated to wait other tasks in its task group to continue. In other words, tasks of
the same task groups always jump simultaneously when this operator is used.
State transition operators come with two forms, prefix and infix. Below is the syntax explanation
of these usages. Prefix usage can be achieved by omitting the first parameter.
any_valid_line_expression --> state_name #infix non blocking
any_valid_line_expression -> state_name
#infix blocking
--> state_name #prefix non blocking
-> state_name
#prefix blocking
3

4. Having an infix form grants these operators the ability to be used with instruction bypassing. If
the expression on the left hand side of the transition operator is discarded by a once member short circuit,
branching is discarded as well. Instruction bypassing therefore becomes a way to conditionally branch in
Doppl as well. Previously demonstrated pseudo program can now be implemented with only a few lines
of code.
#States explained
task(10) States {
once shared data output_data = string
shared data
temp_data
= string
data
input_data = string
init: {
output = "I am ready!n"
->load #Everyone waits the load
}
flush_and_load: {
input_data = 0
shared_data = ""
output_data = Null
input_data = input
-->process #The one who loads may continue
}
process: {
temp_data = temp_data ++ input_data #Calculation
->render #Everyone waits till completion
}
render: {
output_data = temp_data
output = output_data #only printed once
-->flush_and_load
}
}
This program highly resembles a double buffered rendering loop in graphic libraries such as
OpenGL and DirectX. In fact the parallel nature of Doppl imitates GPU cores to achieve same effect by
using task groups. The main design principle behind Doppl aims that such mechanisms should be easy
to implement and should take fewer lines of code when compared to other general purpose programming
languages. This ability also suggest that Doppl programs can become GPU friendly if they suffice some
4

5. limitations. Observation of this claim is beyond these iterations and can be subject to a future research.
4. States Within States
It is possible to define new state blocks inside of states as long as the proper naming convention is
used for branching. In order to branch to a new state within a state, the state name should be prefixed with
parent state name followed by a period '.' character. There is no limit for nesting levels. Name collision
for states will be explained in the next section.
mystate: {
#valid
mystate.foo: {
->foo
->mystate.bar
->zip
->mystate.zip
}
#same as mystate.foo
#same as bar
#valid but discouraged
#better than above
#valid
mystate.bar: {
#some calculation
}
#valid but same as mystate.zip and discouraged
zip: {
#some calculation
}
}
Since state block beginnings do not imply any state transition, it is possible to put a state block
anywhere inside another block. Expressions skip state declarations during runtime as they have no
significant meaning in terms of an operation, therefore it is considered good practice to isolate these
declarations from other expressions of the same state during formatting.
5. Scope
Scope rules in Doppl highly resembles scopes in common programming languages with a few
additions to work with state transition properly. Any declared member in a block can always be accessed
by inner blocks but the opposite is restricted. This rule does also apply to states. Name collisions are
handled by latest overridden rule. Below are the results of these rules for each scenario.
1. Any block can access any member and state that it declared.
5

6. 2. If an inner block wants to access a member outside of its declaration, it can only do so by
navigating outwards block by block until it meets the parent task. If the member found
during the navigation, it can be accessed.
3. A state can jump to another state if and only if the jumped state can be accesses by the
navigation method given above.
4. Name collisions during member accesses can be prevented by prefixing member names
with parent states followed by a period character. If the collided member is a task
member, task name followed by a period character can be used as a prefix.
#Scope demonstration
task Scopes(1) {
data mybyte = byte
#init is omitted for demonstration purposes
mystate: {
data mybyte = byte
mystate.foo: {
mybyte
= 0xFF
mystate.mybyte = 0xFF
Scopes.mybyte = 0xFF
otherstate.mybyte = 0xFF
}
mystate.bar: {
->mystate.foo
->mystate
->otherstate
->otherstate.foo
}
#means mystate.mybyte, valid
#same as above, valid
#not the same as above, valid
#invalid
#valid
#valid
#valid
#invalid
}
otherstate: {
data mybyte = byte
otherstate.foo: {
#some calculation
}
}
}
6

7. 6. Conclusion
Iteration #9 explains states, a special entity type which can contain executed code as well as their
own declarations. Synchronization, branching and loops are implemented via transitions between states
which has its own kind of operators. Blocking transitions act like barriers which synchronizes tasks of the
same task group at a specific point. Non blocking transitions are used of branching within a single task.
7. Future Concepts
Below are the concepts that are likely to be introduced in next iterations.
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Target language of Doppl compilation
Parameterized branching, states as member type, anonymous states
if conditional, trueness
Booths (mutex markers)
Primitive Collections and basic collection operators
Provision operators
Predefined task members
Tasks as members
Task and data traits
Custom data types and defining traits
Built-in traits for primitive data types
Formatted input and output
Message passing
Exception states
8. License
CC BY-SA 3.0
http://creativecommons.org/licenses/by-sa/3.0/
7