This is the most beautiful thing I’ve seen in quite some time. Leaning on stack orientation to obviate the monad/dyad duality is an interesting choice, the choice of glyphs is great, the auto conversion from “human typable” names is nice.
Yeah, I’ve tried to get into J and apl a couple of times, and the whole monad/dyad thing and the trains and forks just doesn’t want to stay in my head, but this just makes a lot more sense to me :)
I can already feel my mind being stretched in ways I didn’t know existed.
I don’t know whether I should be thinking this, but I’m wondering whether there’s a facility for translating glyphs back to the names*; I feel as though that might help me embrace the language a little more. But perhaps not having that facility might help more.
*a quick scan of the docu didn’t reveal anything about this, unless I missed it.
Thanks, yes - I started doing that, but I was thinking more about “translating” a Uiua program to the non-glyph version, to be able to stare at it in “English” first (I realise I didn’t make this clear in my message earlier, sorry).
Looks cool! I immediately thought of BQN, and on the Design page indeed says BQN is the main inspiration. Interested to spend more time looking into the different decisions it makes. Maybe I’ll try this for AoC this year.
Really cool! I like the right to left evaluation and the sort of currying behavior of parentheses. Using functions for boxing / ragged arrays is clever.
I am wondering how it decides whether to apply a function or push it. For example ‘f x’ applies f, but ‘each f x’ must push f to the stack so ‘each’ can call it? Maybe the evaluation rules for operators/adverbs are special?
I think that’s right: the evaluation rules for operators/adverbs are special. And built-in operators are sometimes parsed differently from user-defined functions. I haven’t actually used it, so someone correct me if I’m wrong.
I like having the function name before the arguments like this:
map (+10) [1,2,3]
add (square 3) (square 4)
In a stack based language, normally you evaluate left to right. But each word is separate, and expects its arguments to be on the stack already. So you put arguments first:
[1 2 3] (+10) each
3 square 4 square add
If you evaluate right to left instead, it looks more like nested expressions, even though it’s actually stack-oriented:
each (+10) [1 2 3]
add square 3 square 4
I would still read these left to right. Maybe I imagine the data sitting inert on the right, and then the functions kind of “attack” it, moving left to right toward the data. I think I also like seeing the root node of the expression first, because it can tell you the high-level structure while the arguments fill in details.
Functions don’t get pushed to the stack unless wrapped in parens. So f x just called f on x. If you wanted to put f on the stack, you would do (f). ! is call. So to put f on the stack and call it on x would be !(f) x.
Edit:
Modifiers are special and will grab a function defined after them in the source. They do not pull from the stack.
Unicode equivalents is a great idea that makes it easier to onboard from non-APL backgrounds, and I/O primitives along with image and sound support make it usable in a practical context from the get go. Now my favourite question: what about performance?
This is the most beautiful thing I’ve seen in quite some time. Leaning on stack orientation to obviate the monad/dyad duality is an interesting choice, the choice of glyphs is great, the auto conversion from “human typable” names is nice.
Really, really great work. It’s just beautiful.
Yeah, I’ve tried to get into J and apl a couple of times, and the whole monad/dyad thing and the trains and forks just doesn’t want to stay in my head, but this just makes a lot more sense to me :)
I’ve been fixated on stack oriented and concatenative languages lately, especially Factor, so I’m looking forward to reading the tutorial.
But as someone who’s never done APL I don’t prefer all those symbols to English words. Maybe I’ll get used to them.
They are much easier to get used to than you’d think.
I think it’s a great improvement that all the symbols have ASCII equivalents. It makes for a much gentler learning curve.
The transpose glyph being trans-flag themed is really cute, and fun
Wow. I hadn’t noticed. Thanks!
I’ve been experimenting with Forths lately and APL/array languages have been in the back of my mind for a while so this is just perfect
I can already feel my mind being stretched in ways I didn’t know existed.
I don’t know whether I should be thinking this, but I’m wondering whether there’s a facility for translating glyphs back to the names*; I feel as though that might help me embrace the language a little more. But perhaps not having that facility might help more.
*a quick scan of the docu didn’t reveal anything about this, unless I missed it.
If you hover over a glyph, it should give you the ascii name (which is an alias).
Thanks, yes - I started doing that, but I was thinking more about “translating” a Uiua program to the non-glyph version, to be able to stare at it in “English” first (I realise I didn’t make this clear in my message earlier, sorry).
Looks cool! I immediately thought of BQN, and on the Design page indeed says BQN is the main inspiration. Interested to spend more time looking into the different decisions it makes. Maybe I’ll try this for AoC this year.
Really cool! I like the right to left evaluation and the sort of currying behavior of parentheses. Using functions for boxing / ragged arrays is clever.
I am wondering how it decides whether to apply a function or push it. For example ‘f x’ applies f, but ‘each f x’ must push f to the stack so ‘each’ can call it? Maybe the evaluation rules for operators/adverbs are special?
I think that’s right: the evaluation rules for operators/adverbs are special. And built-in operators are sometimes parsed differently from user-defined functions. I haven’t actually used it, so someone correct me if I’m wrong.
I’m learning Uiua a bit but I don’t yet see why right-to-left makes sense. Can you or anyone else share a perspective on that?
I like having the function name before the arguments like this:
In a stack based language, normally you evaluate left to right. But each word is separate, and expects its arguments to be on the stack already. So you put arguments first:
If you evaluate right to left instead, it looks more like nested expressions, even though it’s actually stack-oriented:
I would still read these left to right. Maybe I imagine the data sitting inert on the right, and then the functions kind of “attack” it, moving left to right toward the data. I think I also like seeing the root node of the expression first, because it can tell you the high-level structure while the arguments fill in details.
Functions don’t get pushed to the stack unless wrapped in parens. So
f xjust calledfonx. If you wanted to putfon the stack, you would do(f).!is call. So to putfon the stack and call it onxwould be!(f) x.Edit: Modifiers are special and will grab a function defined after them in the source. They do not pull from the stack.
Unicode equivalents is a great idea that makes it easier to onboard from non-APL backgrounds, and I/O primitives along with image and sound support make it usable in a practical context from the get go. Now my favourite question: what about performance?