@Adám , yes, I am. I just wanted to ask you guys what "6::" is. By I figured it's an error-guard in dfns. Is this feature only supported by Dyalog APL?
Pushed my array formatting (including: •Out for direct output, only accepting certain atoms and char vectors/matrices, and making ⍕ use those same rules; •Pretty for getting a prettified form, with a left argument of 1/2 for formatted/single-line, potentially adding number formatting rules later; )ln to toggle single-line mode or )ln expr to use it once), that drawing system thing, and •Comp optionally taking 2 extra args of indices & source
@Marshall it's using java's built-in formatting, though it should output the exact value imo. the default pretty-print formatting has •pp←14, which discards the last couple digits otherwise
though now i'm reminded that •pp has no effect now. But I planned to remove it anyways & replace it with )pp or similar, as it's a Sys-wide setting rather than scope-wise, and should only be used by the REPL
(another question is how NaN is treated, since currently it mostly exists)
BQN's REPL page now has an expression explainer! The "Explain" button activates it.
This tool uses the compiled source to show the flow of evaluation through an expression. It doesn't yet handle lists or multiple expressions, but these should be fairly easy to add. Also no support for blocks, which will be harder.
I could also do something to illustrate the type of operation being applied, perhaps with colored lines or hovertext.
@dzaima Every instruction should have a start and end position fairly soon, so you won't have to worry about tokens. Then function and operator application could have carets covering all parts of the application like dzaima/BQN does.
e.bqn uses the tokenizer output mainly so it has access to token roles.
@Adám i'd guess that the ratio of filling in those being a bug rather than a feature is quite high (except slashes where it kind of has to be intentional)
(and if ↑ took an argument of a fill element, a working solution would be to use the argument array itself as the prototype, and then remove itself from the ↑ed array :D)
@Adám yeah, I've found it to be quite useful. (as a side-note, I encounter (+/,) quite often too, but having a flattened reduction operator would feel kind of useless)
@Adám I don't think I'd describe the implementation that way either: it treats the right argument's leading axes as one virtual axis. Sure, you have to find the length of that axis by multiplying numbers one-by-one, but I think it's weird to describe that as a series of merges.