To-do list for Tock
-------------------

## General

## Data structures

Think about simplifying the subscript types -- just have a single data type
that takes several expressions.
(Multi-subscript expressions like a[x][y] currently get pulled up into an array
slice, which is inefficient.)

Eventually (not yet), channel formals should take a direction; this should
either be given directly using decorators, or inferred from the code that uses
them.

## Support code

Types needs cleaning up and Haddocking.

## Driver

Add an option for whether to compile out overflow/bounds checks.

## Parser

## Passes

Come up with an approach to combining simple passes to avoid multiple tree
walks (for example, giving passes a "next thing to try" parameter).

Expression simplification -- this should use generics, so that we can have a
default behaviour that simplifies expressions inside another one.

Output item expressions should be pulled up to variables.

We should generally try to reduce the number of unnecessary pullups we do:
- plain subscripts that result in a non-array shouldn't pull up (e.g. x[i][j])
- expressions that are already a variable should just be turned into the variable

Pass to turn complicated conversions into simpler ones (currently done in
GenerateC).

Have a final pass that checks all the mangling has been done -- i.e. function
calls have been removed, and so on.

In the PAR wrapping pass, wrapper procs should not be generated for things that
are already PROC calls.

## C backend

We could have genSpec generate {} around specs if it's not immediately inside
another spec (which'd require some extra boolean arguments to find out).

If the assembler-analysis approach to working out process sizes works, then we
can put the sizes in variables in a separate object file and only
generate/compile that after we've done the main one.

IF could detect, like CASE, whether it's got a TRUE branch.

IF could generate a simple if ... else ... without the gotos and label when
there's no replication or specs.

genParRep uses a C99 dynamic array for a dynamic PAR count, which may turn out
to be a bad idea for very large counts (since I assume it'll allocate off the
stack). We should probably do a malloc if it's not determinable at compile
time.

Slice checks should not be generated if the slice is known to be safe.

PLACE should work.

Array comparisons generate silly code (rather than failing).

Pullups don't work properly for this at the moment, because index changes after
the pullup:
  c ? index; [array FROM index]
(Tested in cgtest12.)
The sensible fix would probably be to make input items Structured, so we can
insert extra stuff into them.

The range checks are probably a bit expensive in stack terms at the moment -- I
need to check what EXTERNAL_CALLN actually does. If it's really bad we could
find a less expensive approach, such as being able to call SetErr with more
parameters.

## tock_support

No overflow checking is done on most operations.

Real-to-integer conversions don't work correctly.

## Usage checker

Not written yet, obviously...

Use a separation logic idea -- at any point in the program, we have a set of
resources. When you go parallel, you have to divide up the resources among the
parallel branches -- e.g. splitting a channel into read and write ends, carving
up an array, and so on. The safety check is done by making sure the resources
are actually divided up.

## Long-term

If we have constant folding, we're three-quarters of the way towards having an
occam *interpreter*.

Matt suggested that the TDS C compiler could be used to produce Transputer
bytecode from Tock's output (if Tock could be persuaded to generate ANSI C).

There should be a CIF interface to the Transterpreter runtime.

It would be possible to support GUY/ASM blocks on top of the Transterpreter
runtime, although I'm not sure how useful that really is.