Memory Model | Code vs Data | Constraints |
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'.
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:
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.