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.
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.
types. Something like "const" or "final".
For now protocol buffers can be used to store and retrieve data.
but it is predictable. There is no unpredictable garbage collection freeze.
The next step is to use a separate thread to manage memory. The main threads write
information about references to the manager thread, so that management does not slow
down the main work.
An alternative is to use another mechanism: A multi-threaded sweep through used items,
after which one thread releases unreachable items.
and with runtime files that can be installed separately. And for ZWT generating
multiple versions for browser+language combination.
nicely together and be consistent.