REBOL was never meant to be anything more than interpreted. It abuses its own interpreter.
thinking about how in Lua and Janet when you define a function its actually tossed to the byte compiler and stored in variables. the compiler is simultaneously running itself but also the program. this is kind of some neat shit actually, and is the basis of Terra/Lua (RIP.)
thinking if i did end up with a rebol interpreter clone i would do something similar to terra/lua. everything runs in the interpreter unless you specifically ask for something to run in the byte machine/jit/whatever. mostly because rebol allows for some truly insane shit (the syntax does not specify how many parameters belong to a function; you have to know at interpret time), and perhaps we should just allow that, and have you explicitly state when you are willing to trade off limitations for speed.
there is no compile step. like Janet and Smalltalk, you just run a script and the final act of the script is to commit the RAM dump. terra/lua does this too. i think its probably a good way to do it.
with REBOL being intentionaly lispy and self-rewriting, i've been interested for years about how they abuse that to get the lines of code way down for their tasks.
like instead of illegible C soup, we just have a dialect with the math expression to do some pixel operation in a paint program. and then we have a notebook interface (a la python) where we can run a transform on the block, get a new block, and print it to the programmer like the compiler explorers, so you can actually see how the transform layers work and turn the math expression in to SIMD optimized streaming kernels.
those layers would also be able to issue complaints/suggestions. so they could in theory explain an optimization it didn't use because it wasn't certain, and you can come back and tell it actually this is fine go ahead assume it is or maybe you just accept the limitation.
there are whitepapers to do all of this but no actual will or interest in doing it. Nile proved that Cairo, Skia, et all, are exponentially more expensive in maintenance than they need to be...
anyway. boobies.
thinking about how in Lua and Janet when you define a function its actually tossed to the byte compiler and stored in variables. the compiler is simultaneously running itself but also the program. this is kind of some neat shit actually, and is the basis of Terra/Lua (RIP.)
thinking if i did end up with a rebol interpreter clone i would do something similar to terra/lua. everything runs in the interpreter unless you specifically ask for something to run in the byte machine/jit/whatever. mostly because rebol allows for some truly insane shit (the syntax does not specify how many parameters belong to a function; you have to know at interpret time), and perhaps we should just allow that, and have you explicitly state when you are willing to trade off limitations for speed.
there is no compile step. like Janet and Smalltalk, you just run a script and the final act of the script is to commit the RAM dump. terra/lua does this too. i think its probably a good way to do it.
with REBOL being intentionaly lispy and self-rewriting, i've been interested for years about how they abuse that to get the lines of code way down for their tasks.
like instead of illegible C soup, we just have a dialect with the math expression to do some pixel operation in a paint program. and then we have a notebook interface (a la python) where we can run a transform on the block, get a new block, and print it to the programmer like the compiler explorers, so you can actually see how the transform layers work and turn the math expression in to SIMD optimized streaming kernels.
those layers would also be able to issue complaints/suggestions. so they could in theory explain an optimization it didn't use because it wasn't certain, and you can come back and tell it actually this is fine go ahead assume it is or maybe you just accept the limitation.
there are whitepapers to do all of this but no actual will or interest in doing it. Nile proved that Cairo, Skia, et all, are exponentially more expensive in maintenance than they need to be...
anyway. boobies.
Follow
@icedquinn every interpreted language eventually arrives at a point where it curses the parts of its design that prevent it from being at least partially JIT-compilable.
IIRC Erlang recently mainlined JIT support by default. Erlang is nearly 40 years old by now.
