|
|
|
|
|
by susam
422 days 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 (Turtle graphics but with only 6 commands) 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. |
|
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
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.