proj-oot-ootMainSemantics

Part of Oot Details.

Read Oot first.

Invalid behavior

These provide some clear examples of what we mean when we say that Oot does not prioritize performance; in (almost?) every case, we choose the inefficent, safe/non-surprising solution.

Whenever possible, we eschew 'undefined behavior' and instead specify that invalid code or behavior leads to either: a compile time error, a runtime exception, or returning an undefined value

now, onto the specifics:

?not sure, todo:

The environment

Variables and labels and functions are all in the same namespace.

Semiglobals

note: semiglobals are like the 'environment' variables in GNU/Linux; eg:

$ echo $hi

$ bash
$ export hi='there'
$ echo $hi
there
$ bash
$ echo $hi
there
$ exit
$ echo $hi
there
$ exit
exit
$ echo $hi

$

.get and .set

.get must not have side-effects (in the current state mask).

.set must be idempotent (in the current state mask).

(why do we say 'in the current state mask'? because this allows for eg profiling or logging code to be executed within a .get or .set)

(todo; should we require that (x.set a; x.get == a)? i suspect no, because that would prevent eg using .get and .set to access locations in shared memory, which could be changed by another process in between the set and the get.)

functions are objects

(todo: ? is there a protocol 'apply' for them? what about closures? do we use Python's func_closure?)

how module loading works

To minimize PATH manipulation, the PATH must be manipulated via the path_insert() and path_remove() functions. To minimize filesystem queries, the contents of filesystem directories in the PATH may be examined and cached at any time (they may or may not be examined lazily rather than at program start); you must call the system path_cache_invalid(subpath) function if you need to discard part of this cache after a possible mid-runtime change in the contents of these directories.

The init() functions of modules are run at some point before the namespace exported by a module is accessed by other modules, but possibly lazily, in parallel, and in any order. A module may import a module that imports it (cyclic imports are allowed). However, the init()s of modules must not cyclicly depend on one another.

If a module is imported by multiple other modules, these may or may not be realized as separate instances of the module.

Authentication

A module is considered 'weakly authenticated' or just 'authenticated' if it is signed by a public key trusted by the implementation (typically this will include keys given on the commandline and keys in a persistent keystore), and if all of its imports are authenticated (or, in the case of cyclic imports, if all modules in the cycle are signed by a public key trusted by the implementation). It is considered 'strongly authenticated' if it is authenticated and all of its non-official import statements include an inline public key or public key hash, and all of its imports are strongly authenticated (or, in the case of cyclic imports, if all modules in the cycle meet these conditions).

Oot implementations may include commandline switches to determine:

misc