Fundamental operations and IR:

I think all the operations a typical user would call, like `+` or `*`, should be defined in a library written in Singeli, possibly auto-loaded. There will only be a small number of built-in functions, and in a sense the frontend is just a very extensible language built around these.

- `result = emit{opcode, result type, arg0, arg1, ...}`
- `result = call{function (value or symbol), arg0, arg1, ...}`
- `slot = declareLocal{type}`
- `handle = beginFunction{arg0 type, arg1 type, ...}`
- `endFunction{handle}`
- `handle = beginGoto{direction}`
- `endGoto{handle, condition(?)}`

(Maybe we want something more sophisticated than gotos. I don't know yet. Maybe I'm forgetting functionality as well).

In addition to their effect on the IR output, these primitives return values to be used in later computation. `result` is a read-only reference to the result of the computation. I think it's easiest to use a static single assignment (SSA) form like LLVM, so that each instruction in the IR of a single unit (function?) is given an ID number, and later instructions can use this number. In this case, a `result` is an ID number, possibly with an additional field to describe in what context it's valid (but maybe we can design our function calls in a way that makes the context unneeded).

Evaluation sketch:

```
# Brackets in an assignment target indicate compile-time arguments.
# Arguments can be unbound names (possibly duplicated), or values.
# Conditions on those arguments are written after, with & .
# : declares a variable and => constructs a function.
safe_double{T & T<u64} = (x:T) => {
  y:2*T = Cast{2*T, x}
  y + y
}

# Overloading
safe_double{f64} = (x:f64) => x+x

'double_u32' = safe_double{u32}
```

In the compiled output `double_u32` should be exported as a single-instruction function (not counting register moves): it adds its argument to itself with 64-bit addition and then returns that value.


What happens when `safe_double{u32}` is evaluated? This happens during compilation. The environment is keeping an ordered list of definitions for safe_double. It tests them in reverse source order to see if one fits the given argument(s): `{f64}` doesn't but `{T & T<u64}` does, since `<` on types means "subtype". This function is then run.

The braces in the definition of `safe_double` don't actually introduce a scope; the scope starts after `=` when a compile-time function is defined. So `x:T` and `y:2*T` occur in the same scope.

`x:T` defines the value `x`, and sets its value to be a compile-time typed variable slot—in the compiled code this will probably be a particular register. The operator `=>` takes a list of these variable slots on the left and source code on the right. Operators always take their arguments at compile time, although an operator might alias to a runtime function (for example `x ** y = fn(x,y)`). I don't know exactly how source blocks should work, but they should be passed unevaluated as arguments so that functions can control how they are evaluated or evaluate them multiple times (for example, for loop unrolling).

What `=>` does is to emit a function header (whatever that looks like in IR), and then just call the source code block. The source code creates a variable slow `y:2*T`, which works the same as the slot for `x`; `2*T` doubles the size of type `T`. Then it calls `Cast{2*T, x}`, which does two things: it *emits* a cast instruction (which should probably exist in the IR, but be eliminated later, as 32-bit unsigned ints should already be stored as 64-bit in x86), and *returns* a handle for the result of this instruction. By passing this handle instead of a symbolic representation of the computation, the compiler ensures that a given piece of source code doesn't get duplicated in the compiled output. Then `=` moves the result (using its handle) into register `y`. Here `=` is doing something very different from the top-level `=`s that define `safe_double`; they are distinguished by the left argument but maybe they should have different symbols. `y + y` is another computation; it emits an add instruction and returns a handle for the result. Finally the function code moves this value to a result register, or otherwise marks it as a result in the IR output.

After `safe_double{u32}` is evaluated, `'double_u32' = ` exports it as a function. The value `'double_u32'` is a symbol, in the C library sense.

Overflow handling:
* Default is to wrap
* Saturation
* Get high/low halves
* Call different code if any (masking?) value overflows

Ways to convert between types:
* Reinterpret, if they're the same size
* Cast each value (lossy for decreasing size)
* Saturating cast, sometimes
* Replicate entire value to fit a larger type
* Replicate individual values
* Select one element, or a slice

Type operations:
* `*T`: sequence of `T`, passed as pointer
* `[n]T`: fixed-size list of `T`, passed in registers
* `$T`: register full of `T`

Atomic types:
* `i8`/`i16`/`i32`/`i64`
* `u8`/`u16`/`u32`/`u64`
* `u1`
* `f32`/`f64`