5. validation.md

Without us specifying any further constraints one may define variables or types with the same name. So we introduce rules for the various identifiers that are found within a program. 

Secondly, imports introduce identifiers into the module scope. Identifiers of procedures and types imported into a module may not conflict with one another, the global scope (which is implicitly already satisfied, unless the import becomes aliased), or the types defined within a module. The identifier we insert into the module scope depends on the type of import: if the import is aliased then we insert the alias, otherwise we insert the name of the imported type/procedure or last section of the module's name.

The same rules apply to labeled statements. Albeit in a simpler form, as labeled statements can only appear in the bodies of procedures. Defining labels will add the label to the current scope. These labels may not conflict with labels in the same scope or labels in parent scopes.

Any other case should be a compile-time error. Some examples:

```

// With a single argument

func maximum<T>(T a, T b) -> T {

    if (a > b) return a;

    else       return b;

}

// Used as

u32 zero = 0;

maximum(zero, 5); // fine, no argument is specified, so `T` will be inferred.

maximum<auto>(zero, 5); // fine, practically the same as above

maximum<u32>(zero, 5); // fine, T is explicitly `u32`

maximum<u32, u64>(zero, 5); // error: mismatch in arguments specified and polymorphic variables on definition.

```

Assignment expressions may only be placed at the statement level. That is to say: viewing a complicated expressions as a tree, where each node has a parent expression or a parent statement (e.g. the test expression of an if-statement), then assignment expressions may only have the expression-statement as a parent.

An enum literal is valid if its `TypeRef` points to an enum declaration (either directly, or through a potentially aliased import) and the subsequent identifier is a variant declared in the type definition. Some examples:

```

enum Answer { Yes, No };

// Used as:

auto a = Answer::Yes; // Valid

auto b = Answer::No; // Valid

Answer c = Answer::Yes; // Valid

auto d = Answer; // Invalid: points to the type instead of a variant

auto e = Answer::DoesNotExist; // Invalid: no such variant defined on `Answer`

```

```

union Value { Empty, Unsigned(u64), Signed(s64) };

// Used as:

auto a = Value::Empty; // Valid

auto b = Value::Unsigned(5); // Valid

Value c = Value::Signed(-123); // Valid

auto d = Value; // Invalid: points to type instead of variant

auto e = Value::Empty(5); // Invalid: `Empty` has no embedded types

auto f = Value::Unsigned; // Invalid: Variant `Unsigned` expected 1 embedded value, none are provided

auto g = Value::Signed(-1, -5); // Invalid: Variant `Signed` expected 1 embedde value, 2 are provided 

```

```

struct Pair { u32 left, u32 right }

// Used as:

auto a = Pair{ left: 0, right: 1 }; // Valid

auto b = Pair{ right: 0, left: 1 }; // Valid

auto c = Pair; // Invalid: Points to type instead of constructing literal

auto d = Pair{}; // Invalid: Not all fields specified

auto e = Pair{ left: 0 }; // Invalid: Not all fields specified

auto f = Pair{ left: 0, center: 5, right: 2 }; // Invalid: field `center` does not exist

auto g = Pair{ left: 0, left: 0, right: 2 }; // Invalid: field `left` specified more than once

```

Again viewing a complex expression as a tree: A binding expression is only valid if it is nested in the expression tree under a statement, or under a chain of parents that are all binary expressions of the logical-and variant. The chain of parents must terminate at an if-statement's or while-statement's test expression. As a result of these rules, binding expressions may not be nested in one another.

The interpretation of the binding expression is that it tests for equality between the left hand side and the right hand side. Except for those places where a binding variable is used, here no equality test is applied. Rather, the value from the right hand side is assigned to the binding variable on the left hand side. Hence if you use an expression containing e.g. regular variable inside a binding expression, then no binding will occur. Instead, the resulting value from that regular variable expression will be checked for equality against whatever is on the right hand side of the binding expression.

The parent of a binding variable may only be some kind of literal expression, or the left hand side of the binding expression itself. Some examples:

```

// Example only for a struct, but binding expressions can be applied to all 

// kinds of literals (although, for some types, the binding then cannot contain

// any binding variables, and resolves to a test of equality between the left

// hand side and the right hand side).

struct Inside { u32 value };

struct Outside { u32 left, Inside right };

// Used as:

auto v_inside = Inside{ value: 0 };

auto v_outside = Outside{ left: 0, right: Inside{ value: 1 } };

// All valid:

if (let foo = v_outside && let bar = v_inside) { /* ... */ }

if (let foo = v_outside && (5 + 2 == 7) { /* ... */ }

while (let Inside{ value: foo } = v_inside) { /* ... */ }

if (let Outside{ left: 0, right: Inside{ value: foo } } = v_outside) { /* ... */ }

while (let Outside{ left: foo, right: Inside { value: bar }} = v_outside) { /* ... */ }

if (let Outside{ left: foo, right: bar } = v_outside) { /* ... */ }

// Invalid: parent expression that is not `&&`

if (let foo = v_outside || (5 + 2 == 7)) { /* ... */ }

// Invalid: not nested under an if/while statement

let foo = v_outside;

// Invalid: binding variable is used in a more complicated expression

while (let Inside{ value: foo + 5 } = v_inside) { /* ... */ }

```

Several functions are builtin procedures in the language. We'll shortly provide their meaning and their syntax here. Some of these functions cannot be expressed in PDL itself, so some ad-hoc syntax is used instead.

### Get(...)

The `get` function receives a value from an input port. This function may only be called in primitive components and may only be called within sync-blocks. If no value is present then the execution halts until a value becomes available. Upon receiving a value the execution forks in two. One branch will remain waiting for any potentially other messages, the other branch will actually obtain the sent message and continue execution.

If a `get` function is called in a branch that has previously assumed that nothing will ever be sent through the port provided as argument, then that branch is considered inconsistent and will be removed. If a `get` function is called in a branch that has not decided on the firing state of a port then it will be forced to fire without forking of execution.

The get function would be written in PDL as:

```

func get<T>(in<T> input_port) -> T { /* ... */ }

```

### Put(...)

The `put` function may put a value into an output port. This function may only be called in primitive components and may only be called within sync-blocks. 

If a `put` function is called in a branch that has previously assumed that nothing will ever be sent through the port provided as argument, then that branch is considered inconsistent and will be removed. If a `put` function is called in a branch that has not decided on the firing state of a port then it will be forced to fire without forking of execution.

The put function would be written in PDL as:

```

func put<T>(out<T> output_port, T value_to_put) -> T { /* ... */ }

```

**note**: Whether the `put` statement blocks until a corresponding `get` has been performed has not yet been decided. 

### Fires(...)

The `fires` function will check if a port has previously been assumed to fire or not fire. If such a decision has not yet been reached then the execution forks. One branch assumes that the port will fire and the other branch assumes it will not. Otherwise this function returns the firing state of the port: true if it fires, false if it does not.

This function may only be called in primitive components and may only occur inside sync-blocks.

The `fires` function would be written in PDL, if the language would support function overloading, as:

```

func fires<T>(in<T> input_port) -> bool { /* ... */ }

func fires<T>(out<T> output_port) -> bool { /* ... */ }

```

### Create(...)

The `create` function creates a value of the type `msg`. Its argument is the length of the `msg` type. It would be written in PDL as:

```

func create(u32 length) -> msg { /* ... */ }

```

**note**: This function will most likely be removed from the language at some point. This because the `msg` type will be removed at some point, and because it should be possible to reserve size for values of array-like types without setting the length of those values. 

### Length(...)

The `length` function returns the length of arrays and strings. If PDL would support function overloading, it would be written as:

```

func length<T>(T[] v) -> u32 { /* ... */ }

func length(string v) -> u32 { /* ... */ }

func length(msg v) -> u32 { /* ... */ }

```

**note**: As stated above, the `msg` type will likely be removed. The `string` implementation is tentative, so might be changed as well.

### Assert(...)

The `assert` function is used to prune execution branches within components. It works much like an assert would in another language: the assert statement excepts an expression as argument that resolves to a boolean value. If the boolean value is `true` then execution continues. If the boolean value is `false` then the execution branch is removed.

The `assert` function may only appear in components (primitive or composite) and may only be called in sync-blocks. It would be written in PDL, if it would support the C-like "void" type, as:

```

func assert(bool test) -> void { /* ... */ }

```

**note**: Perhaps the name of this function will change in the future.

## Statement Rules

### Synchronous Blocks

### Use of Builtin Procedures

### Control-Flow Rules