From 57f88ba28ab8640594b5619e114dc06493b63812 Mon Sep 17 00:00:00 2001 From: Calvin Rose Date: Sat, 3 Mar 2018 16:16:37 -0500 Subject: [PATCH] Add thoughts.txt for simple roadmap of work. --- thoughts.txt | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 thoughts.txt diff --git a/thoughts.txt b/thoughts.txt new file mode 100644 index 00000000..984459e6 --- /dev/null +++ b/thoughts.txt @@ -0,0 +1,68 @@ +A collection of thoughts and todo tasks for the project. + +- Track depth of C stack in vm. While the VM is stackless, C functions can create + new VM stack frames as needed. We should provide a configurable hard limit on + stack that will simply error out immediately. This would prevent a stack overflow. + +- 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). + +- 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. + +- 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. + +- Serialization and deserialization of all datatypes. This would allow + +- 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. + + +- Implement multi-methods.