min is actually mainly an interpreted language, BUT it can actually as of recently be transpiled to Nim (which in turns generates C code which can be compiled), so you can actually create executable files from min, which is pretty cool.
Adding this form of compilation was actually really easy because in a stack-based language there's essentially one instruction: push an item on the stack... the only things I had to add was wrapping external files in functions to delay their evaluation to when they are required.
Combinators like linrec etc are no different from ordinary operators, they are pushed on the stack and they rearrange it...
Consider the following program that takes an integer as input and prints its factorial:
args
(compiled?)
(0)
(1)
if get int
(dup 0 ==) (1 +)
(dup 1 -) (*) linrec
puts
Note how I am getting the first or second argument from the command line depending if I am running the program through the interpreter (min factorial.min 5) or as a stand-alone executable (./factorial 5).
When running the min "compiler":
min -c factorial.min
...the following Nim code gets generated. As you can see, it's mostly just pushing items on the stack :)
> min is actually mainly an interpreted language, BUT it can actually as of recently be transpiled to Nim (which in turns generates C code which can be compiled), so you can actually create executable files from min, which is pretty cool.
That is pretty cool. I just started learning Nim and I really like it so far.
> ...the following Nim code gets generated. As you can see, it's mostly just pushing items on the stack :)
It looks like you're sort of compiling the interpretation?
The last couple of days I've circled back and got some work done on compiling Joy code. (I'm using Python as the target language. I'd like to use Nim, but I don't want to learn that at the same time as I'm trying to write a compiler; with Python I have a lot of experience and the surprise factor is low. I know where I'm at with it.) I've just now got it to the point where I can compile (integer) math, binary Boolean logic, and loops and branches.
As you can see, the generated Python good is not good. (E.g., it calculates "v2 % v1" twice for no good reason.) But it has the qualities of being correct and I-didn't-have-to-write-it! :)
(The compiler code is written in Prolog. It turns out that Prolog is so good for writing compilers that it's faster and easier to learn Prolog and then write a compiler in it than to try to write a compiler in some language you already know!)
This is messy work-in-progress code at this point, but if you're interested...
ANyway, still to do includes: better connections from step to step so the Python code isn't packing and unpacking the stack variable like crazy. Reuse "free" variable names (right now it just generates new vars as-needed, which is fine, but it keeps the values around until the end of the function call. Maybe they could be GC'd earlier, I dunno.)
That's all pretty straightforward, the tricky bit is handling all the meta-programming: as you no doubt know, a lot of Joy functions work by combining args with function fragments to make new functions which are then evaluated. For example, consider this (kinda silly) function:
[dup] cons i
It's silly because it's equivalent to just "dup", but it illustrates the problem: how do you compile this function (or less-silly ones that work with the same meta-programming style)?
I suspect that you just have to include the interpreter and make "dynamic" calls to it from the compiled function (or include the compiler and JIT compile.) What do you think?
min is actually mainly an interpreted language, BUT it can actually as of recently be transpiled to Nim (which in turns generates C code which can be compiled), so you can actually create executable files from min, which is pretty cool.
Adding this form of compilation was actually really easy because in a stack-based language there's essentially one instruction: push an item on the stack... the only things I had to add was wrapping external files in functions to delay their evaluation to when they are required.
Combinators like linrec etc are no different from ordinary operators, they are pushed on the stack and they rearrange it...
Consider the following program that takes an integer as input and prints its factorial:
Note how I am getting the first or second argument from the command line depending if I am running the program through the interpreter (min factorial.min 5) or as a stand-alone executable (./factorial 5).When running the min "compiler":
...the following Nim code gets generated. As you can see, it's mostly just pushing items on the stack :)