Concatenative Programming Projection 2022 – ***Interleaved 2D Notation for Concatenative Programming*** – by @Michael Homer Some quickly enlightening demo videos here: https://michael.homer.nz/Publications/LIVE2022/article/ <<< THIS IS GOOD Landing page: https://michael.homer.nz/Publications/PAINT2022 Tryable in the browser: https://homepages.ecs.vuw.ac.nz/~mwh/demos/p22-2d-concat/ Direct link to the paper: https://mwh.nz/pdf/paint2022 It's a concatenative language. It's not a stack based language. Slight differences I guess. Also questionably point free with with the values unnamed but live values still shown. Comparison to stack based languages ★ ***Similarities to a stack based language:*** – also no variable names – also the typical operations: dup, swap, dig – also only variables with an arity of one or more (aka functions) are shown (and literals) ★ ***Differences:*** – There's no reverse polish notation. – Unlike in in a stack based language there's no single stack. Rather the representation make opportunities for parallel evaluation quite obvious. – Variables have no names but are still displaying their live value like in a spreadsheet (not referring to the layout). ⚠️ ***It seems this is actually not a language but a projections style.* This is nice, meaning to some degree other language can potentially be projected into this representation. Well, plus-minus some issues. Syntactic sugar mostly not carrying over. Readability in other projections. Switching to a different projection one may want to give out human readable variable names though rather than assigning auto-generated ones. Maybe this would be a viable additional projection target for some other languages (unison)? No clue though how this would interact with algebraic effects. Comparison to ALDs ( http://apm.bplaced.net/w/index.php?title=Annotated_lambda_diagram ) ***Relation of Michael Homers model to annotated lambda diagrams:*** ★ ALDs give same obviousness of parallelity opportunities ★ Unclear which representation is visually denser but likely not the ALDs ★ ALDs (as in the current mockups) are not pointfree. Variable names do appear both … – at the head of the function definition (and tops of let- and in- blocks) and – as annotations of the horizontal value lines (i.e. as the arguments to functions) ★ For Making the ALD code projection more aligned with Michael Homers model: – replace value names with live values – collapse let-in-blocks by substitution (live values could still be added as "syngraphic" sugar in extended value lines, I digress …) ★ flip & dig (argument permutators) – They both vanish in the ALD code projection no matter their location. – They are just permuting the arguments by swapping application lines and all preceding dependents. ★ dup – only vanishes at the top level as it turns into two forks. – otherwise less trivial as it induces an unavoidable let-in block. (Uncurrying into tuples is a bad alternative as it hides away ALD circuitry, the whole point of ALDs)

Thanks, these are really useful comments & comparisons. A bit of follow-up work that may be interesting is https://michael.homer.nz/Publications/PX2023 where it pushes the same model into a graph as well, letting the user switch between views.

@Michael Homer I spontaneously decided to project your example to an ALD mockup to get a bit of a feeling for inhowfar ALDs are compatible with your code projection focused of concatenative code. Seems pretty good. ★ One nice thing with ALDs is that library functions are threated exactly the same as argument values. They come in as semi-implicit arguments via the grey collection abstraction-line. ★ One annoying (but I think good) restriction of ALD is that functions (and definitions in let sections) can only ever have just one single value-line as their final output (except one cheats a bit as I've done here with memocurry 😈).