janet/thoughts.md

Thoughts

A collection of thoughts and todo tasks for the project.

• Allow entrances into the VM to track the size of the stack when they entered, and return when the stack is less that. This would make calling dst functions from C feasible ( The programmer would still have to ensure no GC violations).

  Instead, we can just keep allocating new Fibers when we call a dst function from C. A pool of fibers would mostly mitigate the overhead of allocation. (going with this).

  We can now call into dst from C without suspending the entire garbage collector. A separate function does exactly that.

• Make unknown instruction in vm trap and put current fiber in a new state, 'debug'. This could allow implementation of a debugger. Since opcodes are encoded in one byte, we can use the most significant bit (0x80) to set breakpoints in code, assuming all valid opcodes are in the range [0, 127]. The debugger could simply set the MSB of the opcode for each instruction that was marked. This would allow debugging with 0 overhead.

  We could also add a debugger instruction, much like JavaScripts debugger; statement very easily.

  Lastly, to make continuation after a breakpoint easier, stopping on the first instruction could be optional. This could be as simple as selecting the first 7 bits of the instructions instead of the usual 8 for the very instruction executed after entering the vm loop.

  What exactly should happen on a trapped instruction is another issue. It would be preferable for the runtime to be able to handle a trap in dst, but allow nested fibers to not capture debugging signals unless needed.

  Fiber's currently propagate all states to their direct parent, but perhaps each fiber could have a mask for different signals - error, debug, return. So a single fiber could say capture returns, error, but not debug. Possibly like try - catch in other languages, where we only catch certain kinds of errors. The default fiber would be to only mask debug, so a single fiber could wrap an entire running application for debugging.

• Remove the concept of 'Ast node'. While providing fine-grained source mapping is is reasonably useful, it complicates the implementation of macros and other source transforming operations. Instead, we can key collection types (which have the unique pointer property) to source mapping information in a external data structure, which is specifically for source mapping. This data structure would be a hash table that used pointer equality instead of value equality for entries.

  The compiler would then need to keep track of 'most specific collection' node when compiling, as the value itself would not always be a collection and contain source mapping information.

  As a result, we could remove special forms like 'ast-quote', as well as ast-unwrapping logic which potentially duplicates a fair amount of data. Macros would be easier to write without needing to either unwrap ast values or sacrifice all source mapping.

• Keep track of source file information in the compiler. The compiler could simply accept and extra argument, sourcefile, which woud append the appropriate metadata to all function definitions generated with this one form.

• Serialization and deserialization of all datatypes. This would allow loading of bytecode without needing the compiler present. However, loading C functions is currently problamatic. C functions could perhaps be wrapped in data structures that contain some meta information about them, say home module and types. This could also allow some automated type checking for C functions rather than writing it manually. Some slight overhead could perhaps be compensated for by adding optional ommission of typechecking later for C functions if it can be statically shown the types are sound.

• Better support for custom user datatypes. Tables and structs do work well for creating custom 'objects' and records, but lack ability to differentiate between object style values and data structure style values. For example, simply adding special keys as fields would make plain a table or struct possibly become object-like if the write keys are added.

  A Lua like solution would be a metatables. It would perhaps make sense to only allow metatables on tables, as object like behavior seems to makes most sense on mutable data (?). For example, metatables on a struct could allow non-pure behavior unless they were extremely limited, or purity was enforced somehow. This could break expectations of a struct to behave as immutable data.

  Also, it might make sense that the metatable of a value would actually be a struct, so a metastruct. Implementations of Lua (LuaJIT) do not allow (or do not acknowledge) changing certain values of a metatables after it is set, such as __gc, for performance reasons.

• Actually make a debugger. While the VM changes to enable debugging are relatively simple, make a useful debugger would be another project. At first, simply inspection of the generated bytecode assembly would be a good start. Single stepping, continuation, and inspecting the stack and current fiber would be a start.

  Preferably this would be programmed in dst. The needed functionality could be exposed in the fiber API.

  Later, with information from the compiler, we could inspect variables and upvalues by symbol. The current compiler does not do full SSA optimization, so named values are always accessible in the stack when in scope.

• Create a pool for fibers. Whlie the general purpose allocator and GC can be made more efficient, Fiber's can be well pooled because the allocated stack is large and can be reused. The stack size parameter on dst_fiber could simply become the minimum memory allocated for the stack. (Do a linear search throught the pool).

• Implement multi-methods.