|Kyle Perik b80eda9624 implement inner scopes basically||1 year ago|
|.gitignore||1 year ago|
|chunk.c||1 year ago|
|chunk.h||1 year ago|
|common.h||1 year ago|
|debug.c||1 year ago|
|debug.h||1 year ago|
|main.c||1 year ago|
|memory.c||1 year ago|
|memory.h||1 year ago|
|readme.md||1 year ago|
|value.c||1 year ago|
|value.h||1 year ago|
|vm.c||1 year ago|
|vm.h||1 year ago|
a VM for judo lang
**Disclaimer: ** I don't know anything about c, so currently this is almost completely a carbon copy of the great walkthrough here: http://www.craftinginterpreters.com
The goal of this is to process bytecode that is created by judo in python, which eventually could be implemented in judo
Again, not understanding how low-level code works very much, this plan is pretty vague.
This should not end up being very complex in theory, despite being a weird language. The declarative nature of the language should hopefully be beaten out of it at this point, in a nice format to be run, not doing any crazy processing.
This is just in theory, being more of a project to see if it can be done.
More practically something like this:
s = :( a * b = x ^ 2 ) r1 = s~[ a = 2 b = 4 ].x r1 | out r2 = s~[ a = 5 x = 3 ].b r2 | out
would be solved for each usage, and become straightforward at this point. This means that there can never be ambiguous code, or code that can't really be solved. Like this:
r1 = :(x = (a * b) ^ -1)~[a = 2, b = 4] r2 = :(b = x ^ 2 / a)~[a = 5, x = 3] r1 | out r2 | out
Here, the scope has to be split into multiple ways of solving. Obviously this is not bytecode. But this looks much more like something a typical programming language can run.