Hello! Author of this project here. Thank you for posting this to HN.
A little background about this project: This is a tiny project inspired by the very popular Tixy project (https://tixy.land/). While Tixy supports JavaScript expressions to determine the size and colour of circles in a 16x16 grid, FXYT comes with its own tiny, stack-based language that is written in postfix notation. The input code is evaluated for each cell in a 256x256 grid and the result of evaluation defines the colour of each cell.
Ouch those limitations though. Given the performance problems some of them sort of make sense I guess, but:
* adding "get by index" and "put by index" commands would significantly improve flexibility compared to only being able to access 3 elements of the stack (admittedly less useful given the limit of 8 total)
* if you perform a sort of pre-compilation pass to generate a sort of bytecode (even to just an array of functions, though I would also add an argument field since stack form sucks), and optimize constants like numbers, execution will be much faster.
> if you perform a sort of pre-compilation pass to generate a sort of bytecode
Generate JS and throw it through eval/new Function. The JS engine is going to beat by a mile whatever you can come up with within the constraints of JS.
That's more or less what I did with C50. I wrote a simple translator to turn the stack based code into JavaScript expressions, then created a function via new Function. It came out a couple of orders of magnitude faster than the interpreted version.
[edit] In case people are curious, here are the main differences I've spotted between FXYT and C50
In C50 x and y range from 0..1 across and down the image respectively instead of 0..255.
Only one value is used on the stack at the end of a C50 program. If a program has a | character then the code after the pipe is a second function that places the value returned by the first function into x and processes it three times with y=0, y=0.5, and y=1 to produce R,G,B values.
There are no looping controls in C50 code is executed straight through.
Larger numbers are much harder in C50. Each digit is just placed on the stack, you need to do math to get larger than 9. I debated a system for quite some time similar to how FXYT does it, N1234 is much easier to understand than 45^567*+ but on the other hand single digit numbers double in size. I'm still pondering a good compromise on this point. Certainly N is friendlier to newcomers. A possibility is a modal instruction system where an N triggers the *10+digit mode for digits until the next non digit is reached, and it pushes just the digit if not in N mode.
A little background about this project: This is a tiny project inspired by the very popular Tixy project (https://tixy.land/). While Tixy supports JavaScript expressions to determine the size and colour of circles in a 16x16 grid, FXYT comes with its own tiny, stack-based language that is written in postfix notation. The input code is evaluated for each cell in a 256x256 grid and the result of evaluation defines the colour of each cell.
Some demos:
1. https://susam.net/fxyt.html#XYxTN1srN255pTN1sqD
2. https://susam.net/fxyt.html#XYaTN1srN255pTN1sqN0
3. https://susam.net/fxyt.html#XYoTN1srN255pTN1sqDN0S
4. https://susam.net/fxyt.html#XYpTN1srN255pTN1sqD
5. https://susam.net/fxyt.html#XYN256sTdrD
Visit https://github.com/susam/fxyt for more details.