3 ms·

Thanks! Gonna give it a try now. I've actually developed my own array language inspired by kdb+/q and forth called xs: https://cryptm.org/xs/ https://cryptm.or

by smabie 6y ago

Thanks! Gonna give it a try now. I've actually developed my own array language inspired by kdb+/q and forth called xs: https://cryptm.org/xs/ https://cryptm.org/xs/ It's a little more pedestrian than what you're doing: APL/J have this ethereal magical quality that k/q seem to lack for whatever reason. Probably because of the lack of tacit programming (which xs supports btw). It's a Java world, we array language folks need to stick together. Maybe we can even break the glass ceiling and get array languages used for front-end work in a couple decades!

mlochbaum 6y ago
I'd seen xs before, actually. I spent a while building concatenative array languages (nothing this complex though—file functions! The luxury!) before deciding that I really need some more structure to make sense of the code. A good amount of implementation discussion goes on at https://chat.stackexchange.com/rooms/52405/the-apl-orchard https://chat.stackexchange.com/rooms/52405/the-apl-orchard . I'm sure we'd enjoy your contributions.
- smabie 6y ago
  I think there's a conflict between the essence of array languages (building a DAG of monadic (in the FP sense) operations and letting arrays flow through it) and the one dimensionality of a stream of symbols in a text file. Ben Lynn [https://crypto.stanford.edu/~blynn/c/apl.html https://crypto.stanford.edu/~blynn/c/apl.html] puts it best: "Worse still, tacit hooks, forks, and ranks obscures the beautiful category theory connections: hooks and forks are function composition and application within the Reader monad, while adjusting the rank of a function corresponds to applying functors." Hooks are a structured approach to this problem, while stacks are an unstructured one. And there will always be tension between the two for as long as the current textual model of programming is used (or maybe no matter what representation we use). How obscure are we willing to get in order to get closer to the beautiful DAG we have in our head? I of course don't have a good answer to that, and I think the dominant paradigm of array languages has set to be discovered. APL gets us close, but we clearly agree that there's more work yet to be done. Looking at your bytecode design, I was reminded of this old paper about building APL hardware: http://www.softwarepreservation.org/projects/apl/Papers/197002_An%20APL%20Machine-Abrams.pdf http://www.softwarepreservation.org/projects/apl/Papers/1970... . Not sure how relavent that is, but maybe it'll be the inspiration of a beautiful VM architecture!

by smabie 6y ago

mlochbaum 6y ago

I'd seen xs before, actually. I spent a while building concatenative array languages (nothing this complex though—file functions! The luxury!) before deciding that I really need some more structure to make sense of the code. A good amount of implementation discussion goes on at https://chat.stackexchange.com/rooms/52405/the-apl-orchard https://chat.stackexchange.com/rooms/52405/the-apl-orchard . I'm sure we'd enjoy your contributions.

smabie 6y ago
I think there's a conflict between the essence of array languages (building a DAG of monadic (in the FP sense) operations and letting arrays flow through it) and the one dimensionality of a stream of symbols in a text file. Ben Lynn [https://crypto.stanford.edu/~blynn/c/apl.html https://crypto.stanford.edu/~blynn/c/apl.html] puts it best: "Worse still, tacit hooks, forks, and ranks obscures the beautiful category theory connections: hooks and forks are function composition and application within the Reader monad, while adjusting the rank of a function corresponds to applying functors." Hooks are a structured approach to this problem, while stacks are an unstructured one. And there will always be tension between the two for as long as the current textual model of programming is used (or maybe no matter what representation we use). How obscure are we willing to get in order to get closer to the beautiful DAG we have in our head? I of course don't have a good answer to that, and I think the dominant paradigm of array languages has set to be discovered. APL gets us close, but we clearly agree that there's more work yet to be done. Looking at your bytecode design, I was reminded of this old paper about building APL hardware: http://www.softwarepreservation.org/projects/apl/Papers/197002_An%20APL%20Machine-Abrams.pdf http://www.softwarepreservation.org/projects/apl/Papers/1970... . Not sure how relavent that is, but maybe it'll be the inspiration of a beautiful VM architecture!