Oz

Rangboom will give you a GUIDE and blah blah. Here is today's copy.

OzInferno - Release Guide (cotopriz).

1 - The Limbo Language

The Limbo language has been extended from the original implementation.

Note that the extensions (e.g. fixed point arithmetic) from VN have not been tracked.

Here is a rough list and explanation of the additions.

* sys.m has been split into sys.m and lib.m, respecting the distinction
between what are essentially system calls and what are common calls that
have been promoted to "worthy of being optimized in the kernel".
sys.html and lib.html (also at http://www.chunder.com/ozinferno/man/sys.html etc.)
will one day have links to almost everything.

* keyword "protected" (e.g. Sys->FD) stops users from misuse of system adts.
a protected adt is readonly and you can't make a new one. this solves some
obvious errors (like changing something you shouldn't) and some more subtle
ones (like stub adts having the same signature which allows major mayhem).

* opaque pointers "ref any". think "void *" but type checked. let "a" be a
ref any and "v" be a ref Example. operations on "a" are limited to assignment,
which conveniently covers argument passing and return values.

simple examples:

    a = v;                  # as free as v0 = v1
    v = a;                  # involves a typecheck instruction on assignment
    (v, i) = (a, 27);   # assignment goes deep, so typecheck performed

an indulgent extension is assignment to array slices, very convenient.

    n := len v;
    a := array[n] of ref any;
    a[:] = v;
    # do domething generic - following assignment type checked
    v[:] = a;

see sort.b for an example of this idiom.

* function pointers: "ref fn". function pointers fit well with opaque pointers.
their introduction re-introduces a very useful paradigm. see sort.b for obvious use.

* why should adts have all the fun? a string or a a module can be assigned to and
from a ref any with the same rules and semantics as expected.

* introduction of the "atomic" keyword. despite speculation this has nothing to
do with LANL. it provides a means for performing an atomic action that cannot
be interrupted/subverted by another thread. e.g.

atomic balance = balance + deposit;    # don't lose money
atomic { t := r.a; r.a = r.b; r.b = t; }     # swap stuff

clearly locks and other interesting functionality can now be implemented without
helper threads. there are restrictions on what can be "atomic" - no loops or
function calls - the VM could easily be frozen with their buggy use.

* autoload modules. every programs loads a few modules and either ignores the
error or has a few lines for diagnosis and exit/exception. in the outer scope
a module can be initilaized on load. e.g.

sys := load Sys Sys->PATH;
bufio := load Bufio Bufio->PATH;

the modules will be loaded on parent module load. an exception will be thrown
on error and the autoload is recursive.

* the common idiom of loading a module and calling an initialization function
can be expressed by declaring a function named "load" in the module being loaded.
this function is called after the autoloads so now we have:

lib := load Lib Lib->PATH;
score := load Score Score->PATH;
slock : ref Lib->Lock;

load()
{
    slock = lib->newlock();
    score->amount(180);
}

this is particularly indispensible when using a module with a shared data segment.

* the "rev" keyword was introduced because it's easy, and saves writing the same
function an uncountable number of times.

    r := rev l;

assigns a new list which contains copies of the elements in list "l" but in
reverse order. it is a long lost friend of hd and tl.

* after lists got elevated slightly they cried for more.

a := array[] of l;         # make an array of the contents of l
a := array[] of rev l;   # almost the same but optimize the rev
a := l[2:5];                 # make an a[3] from elements 2 til 5 of l
v := l[2];                    # grab element 2

X - Known problems

* i seem to have screwed up clean up in the compiler, so limbo *.b will give
strange errors. i'll have a look for it one day.

* the JITs aren't up to date ... new Ops not supported. yes, easy but not done.

* if you find any more please tell me