| 24 Jul 2024 |
 Marshall | And I could do some optimization for findmatches{x, range{n}} and findmatches{x, x} to improve them somewhat. | 18:41:20 |
| 25 Jul 2024 |
 dzaima | also a thing in my current code is that I can't use the indices widening to widen u8 to u64 as that reduces the index count from 32 to 8, and [8]u8 loads aren't implemented (and, while that could be made, [4]u8 would still be a problem); so I'd need some abstraction for sub-native-size vectors and thus be unable to destructure their types | 01:37:03 |
| dzaima | (of course here the index widening shouldn't be done by per-loop generated code but rather outside so that the actual loops are shared, but whatever) | 01:41:54 |
| dzaima | unrelatedly, def flip{a} = each{tup, ...a} | 01:53:46 |
| dzaima | has the side-effect of making flip{tup{0}} be tup{0} rather than an error though | 02:00:25 |
| Marshall | Restriction in that it won't handle different lengths any more, but the current version breaks if any element is shorter than the first. So I'll go with that definition, thanks. | 02:00:42 |
| Marshall | Oh, I can add a condition to make sure all elements are tuples. | 02:01:46 |
| Marshall | I think the only reason each{} accepts non-tuples is that I was lazy about the checking, but I'm not totally sure. | 02:04:58 |
| dzaima | I wouldn't oppose making it an error | 02:06:10 |
| Marshall | Yeah, each{tup, 0, 1, 2} returns tup{tup{0},tup{1},tup{2}} which is like a totally different function. | 02:06:24 |
| dzaima | oh huh | 02:07:13 |
| Marshall | (Although a fairly useful one, but of course if it were supported it should also accept tuple arguments) | 02:07:34 |
| Marshall | Also picked up your printf changes, so those will go out when I push stuff. | 02:08:24 |
| Marshall | Pushed stuff. | 02:16:16 |
 _elcaro_ | Minor quibble... In the FromJ docs, /: Dyad ⍋⊸⊏ is missing a swap. It should be ⍋⊸⊏˜.
Same for \:
J:
'listen' /: 3 2 1 6 4 5
silent
BQN:
"listen" ⍋⊸⊏˜ 3‿2‿1‿6‿4‿5
"silent"
| 02:48:53 |
| Marshall | Changed that. I always got those wrong when programming in J too... | 10:49:13 |
|  parker changed their profile picture. | 21:26:52 |
| 26 Jul 2024 |
|  brian_e | 00:32:49 |
| dzaima | some weird Singeli behavior: if (0) = {} doesn't error; def g = if (0) = 2 says that 2 isn't a known infix operator (found via having written a if (0) = { … } else { … } and taking a couple minutes to figure out that the error is at the = despite it pointing at else) | 02:04:49 |
| dzaima | (can replace = with any undefined operator character sequence) | 02:16:09 |
| Marshall | = {} is an operator expression, equivalent to __set{}. So def __set{} = 5; show{ if (1) = {} } prints 5. | 02:17:45 |
| dzaima | ah. fun | 02:18:06 |
| Marshall | The unknown infix operator is a pretty bad error message. Operator parsing is bad about this generally and I doubt it's too hard to improve. | 02:21:01 |
| Marshall | Pushed an improved version: now if the erroring node can't be an operator it infers that instead the previous one was supposed to be a prefix operator but wasn't recognized, and otherwise it gives a missing operand error if there's no right operand and the old unknown infix operator if there is. | 14:03:42 |
| Marshall | I think this might be better handled by assigning operator arity based on whether there's a non-operator to the left, so then it can look up prefix or infix definition based on that and error if it's not found. I don't know if this loses any capabilities. The current Pratt parser will parse + * 1 treating the left + as a non-operator, but I don't think this can ever do anything since in evaluation it tries to look it up as a variable with name "+". | 14:11:32 |
| Marshall | So hopefully this would be an initial error checking step that has clear reporting, and then the Pratt parser gets handed something that will always parse without error, and just has to resolve precedence. | 14:14:35 |
|  busy_hamster_48992 joined the room. | 15:07:22 |
| Marshall | I keep wanting to write a page to argue against statements like "APL is linear algebra made into a programming language" or "since it's in the APL family, BQN must be all about math", and stop when I realize I hardly have anything to say. This time I decided to strip it down to the essentials instead, so here it is. | 17:05:35 |
 icen | I’m enjoying the repeated theme of docs via fanfic and eagerly await the next instalment | 17:42:40 |
 panadestein | When I program in BQN I feel the same joy I felt years ago when proving some tricky identity or solving a transcendental equation. In that regard, I think BQN is like algebra, but not exclusively linear algebra. | 19:24:28 |
