4 ms·

This (along with ibniz) was one of my inspirations for https://c50.fingswotidun.com/ https://c50.fingswotidun.com/ Using a stack based expression approach make

by Lerc 2y ago

This (along with ibniz) was one of my inspirations for https://c50.fingswotidun.com/ https://c50.fingswotidun.com/ Using a stack based expression approach makes it easier to design images at the cost of being less flexible computationally. I have often pondered enhancements to make it more capable,and indeed Turing complete. Forth style word definition would work, but I also have a soft spot for state machines. Little toys like these are things I would recommend everyone have a go at. I have quite enjoyed https://tixy.land/ https://tixy.land/ and https://www.dwitter.net https://www.dwitter.net

susam 2y ago
Very impressive! I have come across your website before as well. I really like how polished and sophisticated the demos are. Great work, and thanks for sharing! I'd like to take this opportunity to share a couple of my own, much less impressive, tools that explore similar ideas: https://susam.net/cfrs.html https://susam.net/cfrs.html (Turtle graphics but with only 6 commands) https://susam.net/fxyt.html https://susam.net/fxyt.html (Inspired by Tixy but stack-based with 36 instructions) To see the demos, click or type '?' and then scroll down to the bottom of the manual.
- Lerc 2y ago
  I like the turtle one. Although I feel like with a minimal number of commands really wants the ability to define new ones. like a:[xyz] defines further instances of a to be [xyz] I think the thing that makes me want it is that it takes a loop 3 deep to recover the characters used to define it. CC is shorter than [C] and CCCC is shorter than [[C]] It's not until CCCCCCCC that [[[C]]] provides a gain. but that's also [[CC]] or [CCCC] Unless you wanted to define things more literally. If you allowed a user defined a to be a literal [[[ and b to be ]F] then you could make some truly incomprehensible programs where it would be nigh on impossible to keep track of the nesting. Sick, but entertaining. CC[[[[[[[[[FFF]FR]FR]FRS]FSR]]]][[FR]]CRRRFR[RFRRR[[[[FFF]]]]]CCCCCCC[[FF]]CCCCCCC[[[F]F]F]CCCC[[[[[[RF]FFR][[[F]]R]R[[[FS]]RS]]]] [update] Late thought alternate theory. Byte pair encoding to create additional instructions. a:bc defines a to be bc so <:[[ and >:]] would define < and > to be double loops (while looking like bert and ernie smilies to boot) but more importantly you'd get some deliciously evil options like X:RR // X becomes RR Y:XX // Y becomes XX which is RRRR Z:XY // Z become XY which is RRRRRR L:ZR // L becoomes ZR which is RRRRRRR which is 7 rights So L is now one left but if redefinition were allowed then A:B: would mean ACD would define B to CD and ADC would change B to DC. I did a few scribbles of ideas and I think there's a ridiculous amount of overly complex power in there.

by Lerc 2y ago

susam 2y ago

Very impressive! I have come across your website before as well. I really like how polished and sophisticated the demos are. Great work, and thanks for sharing! I'd like to take this opportunity to share a couple of my own, much less impressive, tools that explore similar ideas: https://susam.net/cfrs.html https://susam.net/cfrs.html (Turtle graphics but with only 6 commands) https://susam.net/fxyt.html https://susam.net/fxyt.html (Inspired by Tixy but stack-based with 36 instructions) To see the demos, click or type '?' and then scroll down to the bottom of the manual.

Lerc 2y ago
I like the turtle one. Although I feel like with a minimal number of commands really wants the ability to define new ones. like a:[xyz] defines further instances of a to be [xyz] I think the thing that makes me want it is that it takes a loop 3 deep to recover the characters used to define it. CC is shorter than [C] and CCCC is shorter than [[C]] It's not until CCCCCCCC that [[[C]]] provides a gain. but that's also [[CC]] or [CCCC] Unless you wanted to define things more literally. If you allowed a user defined a to be a literal [[[ and b to be ]F] then you could make some truly incomprehensible programs where it would be nigh on impossible to keep track of the nesting. Sick, but entertaining. CC[[[[[[[[[FFF]FR]FR]FRS]FSR]]]][[FR]]CRRRFR[RFRRR[[[[FFF]]]]]CCCCCCC[[FF]]CCCCCCC[[[F]F]F]CCCC[[[[[[RF]FFR][[[F]]R]R[[[FS]]RS]]]] [update] Late thought alternate theory. Byte pair encoding to create additional instructions. a:bc defines a to be bc so <:[[ and >:]] would define < and > to be double loops (while looking like bert and ernie smilies to boot) but more importantly you'd get some deliciously evil options like X:RR // X becomes RR Y:XX // Y becomes XX which is RRRR Z:XY // Z become XY which is RRRRRR L:ZR // L becoomes ZR which is RRRRRRR which is 7 rights So L is now one left but if redefinition were allowed then A:B: would mean ACD would define B to CD and ADC would change B to DC. I did a few scribbles of ideas and I think there's a ridiculous amount of overly complex power in there.