@Adám I'm timing an entire program (Marshall's compiler on 2+2) so i really shouldn't get a 50% improvement there, and for all i knew, there could've actually been a 50% improvement on the actual pervasion of builtins (but testing all combinations of it is really annoying)
also i'm fairly certain that reducing this "20-100ns" by like 3ns would be a pretty big benefit to scalar code
@xpqz it could be - dzaima/APL does check for correctly matched parentheses/brackets, and Dyalog "stores" the error of an unknown character in the source until evaluation
I know some say to use a deliberate syntax error as a way of doing a conditional breakpoint... which seems like a hackbodge to me. It's just a bit tiresome when a long running program fails on a syntax error :)
@xpqz It all depends on the design of the parser/compiler.
There are benefits to merging parsing and evaluation like most APL's do. KAP generates a full tree at parse time. Great for immediate error reporting, but has the drawback of not being able to dynamically redefine a symbol's role for example.
It also means that you have to parse function definitions in the correct order, as a function has to be known before use.
I'd settle for the sort of syntax highlighting an emacs mode or VS Code does to capture the simple stuff. fix already does something -- you can't save a dfun missing its closing }, say.
But the line between IDE and interpreter is much more blurry for Dyalog than A.N.Other language.
@xpqz it'd probably be non-trivial to make sure that {{ 1+⍵ }⍵}¨⍳1000 doesn't result in 1000 re-syntax-checkings of the inner dfn. And regardless, it'd be a thing that'd get caught later anyways and can be checked by an IDE trivially (which RIDE does)
@xpqz it colors things red on mismatched parentheses
(and, along with checking for invalid tokens (incl non-existing quads, which RIDE does) that is pretty much all one can check about an APL expressions validity at compile-time without writing a separate parser just for statically checking syntax, and even that couldn't possibly always work)