I'm a bit confused about what really is being interpreted here, because my reading of the specification indicates that the entire image is read as a single expression in the lambda calculus but the graphic interpreter looks like a procedural execution at the first glance. Is it just a visualization of beta-reduction in progress?
EDIT: I think I got it and I think calling this as an "encoding" is a misnomer. The program starts with a single term `turnstyle(x, y, dir)` which gets lazily evaluated to the actual term. So not only the evaluation might be lazy, but the parsing is also lazy and this is a key point of this esolang which should be highlighted more in my opinion.
This seems cool, but I’m having difficulty understanding the specification. It would be nice if there were some examples of e.g. 2+3 , (lambda f. lambda x. (f (f x)))(lambda y. (y+2)) 3 ?
`2 + 3` would be internally `((prim(3, 1) 2) 3)`, which can be composed of following fragments (where `^>v<` indicates the direction and the position of the current turnstile):
AA
prim(3, 1): >BBB
C
literal 2: AvB
CC
literal 3: AvB
CCC
A
(prim(3,1) 2): >*****prim(3,1)
*
*
2
A
((prim(3,1) 2) 3): >*****(prim(3,1) 2)
*
*
3
So assuming that each distinct letter corresponds to a distinct color, one possible encoding would be:
A A BB
>>BBBBBCCCCCD
B C AD
B C D
CBD DCA
AAA BB
The specification allows for a simple "identity" pattern which can be used to extend otherwise overlapping patterns here. The following, if I did everything right, would be more compact but much harder to decipher:
While both MJ and Turnstyle are Turing-complete, Turnstyle shares more similarities with Piet (mentioned by the author), Wireworld, and, of course, Conway's Game of Life.
Worth maybe calling out that there is a few academic language implementations using this name (turnstile, turnstile+) https://docs.racket-lang.org/turnstile. It's not a standalone language but worth pointing out
EDIT: I think I got it and I think calling this as an "encoding" is a misnomer. The program starts with a single term `turnstyle(x, y, dir)` which gets lazily evaluated to the actual term. So not only the evaluation might be lazy, but the parsing is also lazy and this is a key point of this esolang which should be highlighted more in my opinion.