mirror of
				https://github.com/janet-lang/janet
				synced 2025-10-31 07:33:01 +00:00 
			
		
		
		
	Add thoughts.txt for simple roadmap of work.
This commit is contained in:
		
							
								
								
									
										68
									
								
								thoughts.txt
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										68
									
								
								thoughts.txt
									
									
									
									
									
										Normal file
									
								
							| @@ -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.  | ||||||
		Reference in New Issue
	
	Block a user
	 Calvin Rose
					Calvin Rose