Variables

Running programs use storage for the program (compiled or interpreted) and for intermediate results. All these things (which consume storage or have a memory address) are called 'variables' in Ocean. Not all 'variables' can be changed, not all variables can created whenever or whereever, still, if it is 'real' (a pattern in memory) it is a 'variable'.

static

The 'Fortran' model: no recursion, no stack (so no 'my'), no heap (so no 'an'); There is, however, no such thing as a 'common' area: Ocean will still manage public vs private allocation.
This model precludes threading.

stack

Recursion and 'my' allocation, but no heap (so no 'an');
Nota Bene: stack does not mean 1 (one) stack, just that the functionality of activation records on a stack is allowed. So the threaded (or even fibred) are possible.

heap

The 'C' model: you can manage your own heap: this includes the ability to create dangling pointers and garbage. Ocean has a number of features to help you manage it quickly with a minimum of overhead, but in the end you, the programmer, are responsible.

managed

The 'heap' model extended with a garbage collector. You can still (by using '!') force dangerous behaviour, but the default management is safe.

persistent

Thinkum needed.

It should be obvious, but the memory model must be identical to all elements of a project.

Ocean is based on the following memory model:

1. One or more blocks of 'words' consisting of a fixed number of bits.
2. A block has consequtive addresses.
3. Each block is either read-only or read-write (hardware i/o register restrictions are solved by access constraints), cow-blocks (copy-on-write) are either solved by the OS, or in case of an Ocean OS, solved by an interupt handler.
4. Each block is either private to the process or shared between processes.

Although executable code is also data on another abstraction level, there are different conventions for them, because when programming they are (usually) percieved differently.

'Code variables' are pieces of executable code (q.v. functions). In principle they reside in read-only memory.

'User variables' are pieces of data, which can reside in read-only (for contant pieces), or read-write blocks.

Oceans power lies for a big part in its support for various constraints: the compiler/interpreter will check if certain conditions are met and will inform the user if problems occur. The most important feature is that almost all constraint checking will happen at 'compile-time' and that it will not have any (except where noted) runtime overhead.

Some constraints can be broken. Do do this use '!' with the newly desired constraint. It is an error to use '!' if it was not needed.