| 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. |