It's technically correct I guess, but testing it on TIO would be somewhat weird (since I'd need to copy the function all over the place and )clear after each test case)
@cannadayr Do you have src/cjs.bqn working (I guess that follow-up comment means yes)? If so, getting a test target it as easy as $ src/cjs.bqn "1+1". It's much better to be able to modify the test code so I'd rather not provide any fixed bytecode that would be harder to change.
And yes, I'd implement the VM as an interpreter first on any platform.
Yeah, if I was to start over (BQN…) I'd make a rule that operators treat constant and function operands the same. (I.e. the function computes the corresponding constant/the constant is treated as a constant function.)
(next up i'll probably switch from using (FN[12]|TR3)O to separating the cases to synthetic headers at compile-time; should probably also think about finally adding non-0-depth LOC_ usage (but that'd still leave VAR_ for •s (speaking of which, is there some reason i didn't implement •← with a VARM? ._.)))
@dzaima Don't know if you noticed but the spec currently says a right argument of Nothing means the entire function expression doesn't get evaluated, including the function and left argument. I'm going to change it so all the parts are evaluated but the function isn't called to match the interpreted behavior that both implementations have now. So don't try to match the spec.
@Marshall I have been glancing through that, trying (not too hard) to follow what it's doing
One of the Advent of Code problems from a year or two ago included building a stack language interpreter, and I made one which converted to .Net instructions and ran them, I was trying to gauge if I'd stand any chance of running BQN bytecode with a similar approach
if you ignore src/APL/types and src/APL/errors (and also src/APL/tokenizer/types which are a bunch of tiny classes), you're down to "just" 15 files for the "core stuff". src/APL/Comp.java is the main tokens→BQN bytecode part, and src/APL/tools/JComp.java is the BQN bytecode→Java bytecode part
@TessellatingHeckler assuming C#, there's really not that much of a difference (as in, it's within the somewhat automatically transpilable territory). And as for the bytecode part - you know as much as i did before i wrote JComp.java (and you also have the advantage of knowing some bytecode-ish stuff before too)
it's just that the javascript vm interpreter is 200 lines, and that feels a lot more approachable than "just" 15 files where one of them is 1300 lines and another is 800 lines, y'know? and I have browsers and probably node installed already
@TessellatingHeckler Nothing preventing you from writing an interpreter and then changing it to a transpiler later. That transition is pretty easy to do.
I have a random technical issue: just recently I bought a monitor and when I set the dyalog terp to full screen on that monitor everything feels slightly blurred
@dzaima not the blurring. e.g. the tabs on firefox are fine and so are the VS Code panels
@dzaima the assumptions are correct
to whom it may concern: under Options > Configure I have the "Enable DPI scaling of the interpreter and dev environment" set and the "Enable DPI scaling of GUI application" was not. I tried setting the second one and it didn't work. Unsetting both fixed it
@dzaima ah yes, no, I appreciate the link and pointers into dzaima/BQN, I do! It's not that I was asking if it's possible in general, it's that I was trying to scope whether I personally can do it :P
@Adám turns out that unsetting the first with the second set makes funny things happen. When I opened a help page, it was blurred and it spanned along both my monitors vertically; also the top bar with the windows icons to maximize, minimize and close were outside the top of the top monitor and I couldn't reach them