Hey thanks for all the input while I was in the bed. @cannadayr Initially I was learning to code in APL using Project Euler questions. Looking back on my early solutions I think I have truly made some progress.
@Adám Oh yea, I should mean pi x 10^N where N < 0. I think the idea was from vid of "Numberphile" youtube channel.
<MrMobius> phantomics, cool. what is driving the LEDs?
<phantomics> The LEDs are driven directly by a controller board called the Teensy, which receives data from a Common Lisp application inside of which my April APL-to-CL compiler is used to create light patterns
<phantomics> APL is used in driving the animations and even more in creating stored pixel animations that get played later
<phantomics> You mean how does it interface with the hardware?
<phantomics> The Teensy board hosts a program that directly drives the LEDs, sending electrical impulses to set their state. The program on the Teensy recevies each frame of pixel values via a TCP protocol.
<phantomics> On the computer driving the animation, the Common Lisp usocket library is used to manage the connection to the Teensy. A CL TCP client sends arrays of pixel color values which are generated either ahead of time or in real time using APL.
<moon-child> out of curiosity, has anyone ever experimented with a left-associative apl?
<phantomics> Haven't heard of one, it'd be kind of awkward since English reads left to right and you'd be reading monadic functions and glyphs to the right of the thing they're operating on
<moon-child> it still reads left-to-right, just associates differently. E.G. a×b+c would be (a×b)+c not a×(b+c). For monadic functions, -a×b would be (-a)×b rather than -(a×b)
moon-child: Commonly called LPA in jest. Yeah, I've often thought about that. It would make many things better, I think, but the syntax would also be more foreign and un-English.
E.g. f(g(h(x))) which in APL is f g h x would become x h g f
I.e. I don't think monadic functions should be prefix in such a language.
Which means monadic - and ÷ probably make less sense, and you'd want to use ׯ1 and *¯1 instead, which isn't too bad.
Monadic ! is perfect as suffix, and | work well too.
Dyadic | could take on the same order of arguments as ÷ which is good.
- and ÷ (and |) would become more sensible, with the secondary argument being the "modifier" as per best practices.
⊥ and ⊤ would be more natural with swapped args too, I think. Compare 1 0 1 1⊥2 to (1,0,1,1)₂
* is an interesting function as both arguments can be principal, depending on the intention; inverse of log or inverse of root. Inverse of root makes sense in LPA, just like inverse of log does in APL, but taking a root would be more awkward, and the √ symbol is ill-fitting.
<moon-child> those are interesting notes--and - and ÷ are longstanding sticking points--but I'm also curious what the effect would be on longer expressions
<moon-child> the right-associativity means that expressions read 'top-down' (as opposed to 'bottom-up')
I'm not sure I agree. For short expressions, sure, but for longer… look at my code golf explanations.
Only for very simply code, I explain it LtR. Generally, I have to go RtL, i.e. bottom-up.
LPA would allow statements to wrap over multiple lines, and would make inline multi-line dfns sane.
In current APL:
fifth←{
fourth
}third{
second
}first
In LPA:
first{
second
}third{
fourth
}→fifth
I've heard complaints that end-of-line assignments would be awkward because they won't line up and thus can't be gleaned at a glance, but when I used TI-Basic, which does this, I never really had an issue with it.
<moon-child> I do think that hiding mutation is somewhat of a problem--it's the biggest issue I take with at&t asm, for instance--but for multi-line expressions you can probably put the assignment on its own line, making it not a huge deal
@dzaima 1) yeah, that's a mistake. Should be ⎕A⎕C. 2) Right.
Even though the spec of ⌷ is the left arg, I'm thinking that it'd be a worthy exception, as I think ⌷⍨ is more common than ⌷ and it fits with brackets on the right (if they are to be included at all ― less need in LPA).
@ngn i'm more arguing about using major cells being "the simplest form of indexing", given that it's largely extremely bad in the case of vectors
(imo the "simplest form of indexing", which APL also doesn't have, is to get a single element of an array at a certain position (so (⊂⍺)⊃⍵, ⊃⍺⌷⍵, ⊃⍵[⊃⍺;1⊃⍺;2⊃⍺;…] but no single-char way due to these all overgeneralizing))
pushed various fixes to dzaima/APL, including a 5-8x performance improvement in the dynamic code parser by replacing a true with llSize != 1. (removed 27 items off of the TODO list, leaving 47)
@ngn Selecting cells using nested indices with non-uniform depth doesn't make sense. For example, if the index is 1(2 3) and the array has rank 2, there's no way to put the row you get from 1 together with the enclosed matrix from 2 3.
In BQN you can use⊏⚇1‿∞, which ends up automatically enclosing results from elements of non-simple arrays. But this is weird enough that I wouldn't want it to be a primitive.
Using each number to pick an element from a vector does make sense, but in BQN you need⥊⚇0⊸⊑ since ⊑ assumes indices will be lists.
<MrMobius> does APL do much optimizing in the background? like if I do +/i 1000 (where i is iota) to sum the first 1000 integers, will it avoid creating the 1000 element array in memory and just do the sum?
@ngn There is no array of 1-cells that corresponds to 1(2 3) because flat arrays have stricter structural requirements (rectangular shape) than nested ones.
With floating arrays you can exploit the fact that 1(2 3) is equivalent to (⊂1)(2 3), but that's not "just following" the nesting structure, it's interpreting it in a particular way (why aren't the simple scalars in 2 3 enclosed?).
@Marshall ok, you understand what i want to happen in the 1d case, right? just like -tree negates a whole tree, i want vec[tree] to use a lookup table for the whole tree
there are multiple ways to extend this to multiple dimensions and it's up to the language designer's taste which one to choose
@ngn That's fine for a vector, because it takes 0-cells to 0-cells (or equivalently elements to elements), but it's not consistent for fetching rows of a matrix, because the rank of 0-cells containing numbers should increase but other cells shouldn't.
@ngn When there are multiple extensions available I consider that a strong signal that none of them should become primitives. More so if the extensions are more similar to each other.