mbeckem / tiro Goto Github PK

• to_string() for builtin object types
  Builtin types (containers, result, etc.) should have useful string representations for printing/debugging
• Basic math functions (round, floor, ceil, trigonometry, ...) and constants (pi, e)
• String utilities
  • find/replace/etc
  • maybe even some unicode support? The runtime should enforce utf8

Expose max heap size setting during vm construction.
The heap already supports this internally, it needs to be exposed in the API and tested as well.

The current implementation of module loading is lazy, i.e. the module initializer is executed when a module is imported for the first time.
Initialization should be eager instead, with an explicit start() call once all modules have been registered with the vm.
This would ensure an application finishes initialization correctly and does not error out unexpectedly on, for example, the first request.

Pseudocode:

vm.register_module("a", ...);
vm.register_module("b", ...);
vm.start(callback); // init all modules in the dependency graph, respecting module dependencies

Installing currently does not work if one wants to include the static library.

Tiro should support two modes: BUILD_SHARED_LIBS: true/false

The static library needs extra care, as it needs to be partially linked: dependencies like absl or fmt should be bundled and their symbols should be hidden.

Details:

• https://cristianadam.eu/20190501/bundling-together-static-libraries-with-cmake/

Example:

$ ld -Ur --version-script=api.version.gcc  --whole-archive libtiro_static.a --no-whole-archive ../_deps/fmt-build/libfmtd.a [...]

Currently user defined functions can only specify a fixed number of parameters:

fn foo(a, b, c) { ... }

We should at least support optional function parameters and possibly also variadic functions.

Example syntax for optional parameters:

fn dump(value, pretty = false) { ... }

"?" syntax like in TypeScript (e.g. pretty?) is not a good idea here, i think.
The only fitting default value would be null (i do not want an undefined construct exposed to the language).

Builtin functions and types and entities in std need documentation on the homepage.

Validate bytecode before executing it.
This gets rid of lots of potential throw sites in the bytecode interpreter.

Some places in the vm implementation (e.g. hash table) rely on the internal Layout pointer to remain stable while operating on the object. This will break in the future once the gc moves objects around.

The existing code should be fixed.
There should also be infrastructure to ensure that this error is avoided in the future.

Notes:

• Some functions that are currently methods may have to become static functions instead, as they can no longer work on the raw object.
• Eventually, it would be nice if those functions could become methods on the stable Handle instead

See https://unicode.org/reports/tr31/

Use

• ID_Start / ID_Continue (X?)
• Pattern_Whitespace
  instead of the current implementation

Possible opportunities for saving some code size:

• Better compression of unicode table in common/text/unicode_data.cpp
  • Lots of space is wasted because all entries use 4 byte code point values. Code point ranges in [0, 256) and [256, 65536) can use a different layout.
  • Note that the source file is generated by a python script (which should also be migrated to cog)
• Wrapper around absl::flat_hash_set(/table) for maps and sets of Id keys (e.g. InstId). All of those Id types are simple wrappers around integers (usually u32), but their template instantiations seem to be distinct. By creating a wrapper type that is a simple map of integers we could save some code, although probably not that much because the value the value types would still be distinct.
• Look into the code size of fmt:: symbols

Tools like Bloaty are useful when working on this.

Most usages of TIRO_ERROR() should be replaced with panics. TIRO_ERROR should only be used for hard internal errors.

Depends on completion of #9

The exception type needs support for stack traces.
When an exception is thrown, the N topmost tiro function names should be represented in the trace.

Exact positions within those functions (e.g. line numbers) are currently out of scope because the compiler does not yet emit those information.

Syntax TBD

Use the library in demo projects and/or real world projects

• Better error messages (error codes are fine, but need a situational cstring message)

Needs syntax/language support and a dedicated module in the standard library.

in vm/interpreter.cpp:

// TODO
case BytecodeOp::LSh:
case BytecodeOp::RSh:
case BytecodeOp::BAnd:
case BytecodeOp::BOr:
case BytecodeOp::BXor:
    TIRO_ERROR("Instruction not implemented yet: {}.", op);

The current garbage collector implementation is trivial (mark and sweep with individual malloc+free calls).
This should be improved, some ideas are written down here.

Implement correct floating point parsing, currently only [\d]+\.[\d]* is accepted.

The following code should produce an error:

import does_not_exist;

export func main() {
}

The module import is currently stripped because it is never used.

Exceptions are already supported by the compiler and must be implemented in the vm.

• Correct unwinding behaviour, i.e. call exception handlers and transport exceptions objects
• Unhandled exceptions terminate the current coroutine, the exception object is used to set the coroutine's result (to error)
• Provide a magic std.pcall(fn) (name TBD) function that can catch exceptions thrown by fn

Ensure that string objects in the vm are always utf-8 encoded.

This is already the case for strings created from literals, but the C API and dynamic constructors should enforce this as well.

• VM: Assert that static strings inside bytecode modules use utf-8 encoding
• C-API: Check string encoding, return error if not utf-8
• String constructor: Check string encoding, return error if not utf-8 (maybe also provide a non-panicking constructor function)

A small user guide is required, to document at least the following things:

• Getting started examples
• Language overview, grammar rules and semantics
• Embedding the compiler and vm