aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-08-19Conses and Vectors for my tagging schemeAryadev Chavali
Unfortunately, due to how vectors are implemented, pointers to them are unstable. We need to box them one more time (therefore adding a level of indirection) in order to stabilise them. This is annoying but currently necessary. Even if we implemented vectors as {u64, u64, ptr} instead of {u64, u64, bytes...}, we'd still have the same problem at access - two levels of indirection. I guess size and capacity checks would be one level of indirection which is nice at least, but we're already screwed at the point of doing lookup either way.
2025-08-19Pointer tagging!Aryadev Chavali
Copied from oats, just the basics required for tagging integers or symbols.
2025-08-19Make sym_table_find return the c-string in question directlyAryadev Chavali
I think we fall into a few traps if we return an sv_t directly. Think intent is clearer by returning the c-string directly.
2025-08-19Add sanitisers to buildAryadev Chavali
2025-08-19Separate out implementation to make looking at code files easierAryadev Chavali
2025-08-19Separated out the definitions to clean up a bitAryadev Chavali
We're going to be using C to compile our Lisp eventually, so I need to have a header file for compilation to work. We can still separate out the implementation details into separate files (then generate a shared library for usage in the link stage) but we need this header file to be singular and clean.
2025-08-19200 line symbol table implementation and the first commitAryadev Chavali
Setup build system (POSIX sh), gitignore, basic C file with an implementation of something I really wanted to setup. It just hashes a snippet of lorem ipsum. Testing seems to indicate it's working. That's all it does lol. This is a really pressing matter; all my previous Lisps always just made the strings on the fly and that irked me deeply. I want a smart implementation that really tries to save memory on something as intensive as symbols.