These are the big chunks of work that need to be done, more or
less in the order in which they should be done.
There are many, many small items to work on as well.
And documenting everything is an ongoing task.
A start has been made with the specification, including syntax highlighting
for examples. Many parts still need to be filled in and wording improved.
While working on this tests need to be written to verify the compiler actually
works as is specified.
The intermediate result needs to be stored in a file, using a protocol buffer.
This has been partly implemented: zui.proto is now used for the parser output.
But the parsing is still done every time.
The compiler itself needs extensive tests. This should also locate any
ambiguities in the language. Currently there is a set of tests to verify
the compiler works correctly. However, the main test is building the compiler
itself, and that binary then has to pass the compiler tests.
We need a nice way to test Zimbu programs. Mocks and more.
In a test access is always allowed, avoids "visible for testing" stuff.
Templated classes and methods work. But they are produced for every set of
template types, even though the resulting code is identical. Need a mechanism
to produce the code only once, e.g. for all reference types.
Closures and callbacks - in progress
Callbacks pass extra arguments in a function reference. The caller doesn't
know about them, the called function does get them. Closures are functions that
use variables from their context, without the caller passing them in.
to store structured data.
Status: This is implemented as a compiler plugin. RPC is working between
a ZWT UI and a server,using JSON format.
Need to support more types, options and "import".
Need to support MessageSet.
Need to support RPC between two Zimbu programs (RPC from ZWT is working).
Four string types have been implemented.
The "varstring" and "varbytes" types can be made more efficient by storing
cords and using copy-on-write.
Need a way to make items immutable. Also recursively for composite
types. Something like "const" or "final".
For now protocol buffers can be used to store and retrieve data.
After experimenting with several alternatives a mark-and-sweep method turned out to work best.
The overhead for allocating memory is mimimal (one extra pointer). At garbage collection
time a stop-the-world is unavoidable. Its time is minimized by only doing the mark phase.
When the program uses multi-threading the sweep phase executes outside of the stop-the-world.
At first a reference-counting mechanism was implemented. Unfortunately it adds quite a bit of overhead,
more than 60%. This is not acceptable, therefore this solution was dropped.
Further improvements are to avoid allocating memory and controlling when the GC is run.
and with runtime files that can be installed separately. And for ZWT generating
multiple versions for browser+language combination.
nicely together and be consistent.