@TessellatingHeckler It's okay to remove the assertion; your runtime just won't catch undefined variables and will behave as if every variable's initialized as Nothing.
@dzaima ok; this goes back a day or two ago where I said "that code runs" and you said "but it's supposed to fail", my test "* incorrectly Handles {a}⋄a←6" :D
see the two examples {x-𝕩}5 ⋄ x←1 and {𝕨-𝕩}5 - in both, the value to the left of - reads a variable; the former should error, while the latter should call - monadically
as Marshall said though, you can remove the check and make the two examples do the same thing for a more simple implementation
536 instructions into building the runtime (=times through the instruction switchblock), pops an empty stack twice in instruction case 8 (same situation as before)
if the basics of instruction evaluation, stack manipulation, function calling, blocks, variable assignment, variable modification, stranding, closures, are running, and the core functions are ones I haven't paid close attention to, it's likely they have problems
I'm fairly confident in arr(), str(), list(), m1(), m2()
@TessellatingHeckler Every instruction should have a predictable effect on the stack, and the only control flow is calling blocks. Can you print the stack size in both interpreters and see where it diverges?
@TessellatingHeckler How can they have the same counter but different states then? Byte 476 is in fact 0, so something must be breaking the byte lookup?
Are you printing counter or p? p would probably be more helpful.
Assuming the printout is of counter, I guess it's calling a dyadic function but ends up in the wrong piece of code. Hopefully it's not a complicated derived function.
@Marshall counter is times through the instruction loop, p is not instruction counts because it also changes with LEB number reading, I'll print that too
let's hope this is finally correct: https://dzaima.github.io/paste/#0fL1B1iU5cmY31ypyHhN3GMwA1Kwqs/JoIDJ4it0bUDd72joUJ9qBVqEt9B56KVqJHi5eAHC4mXLAQ9Lif@7@OQD/YIDh/vZf/uPff/vtv/@3//Z//tt//Pa//1//8W//5b//13/77bd//7f/49//l98@/139f/z4/M/rz9@uu/8ff/z5z3/8dhPk//6RPv9L@23894@//6d/JpQIySekv11X/9P/7efvPz8/N/5SCNsnbISlh//pExbCmXCb4fwrnAlrj95phvVXWAkbYZ1h@xU2woVwneHyK1wIV57pnuH6K1wJN8J5htuvcOvh@yJcZvivv8L3RfxGlmvG/zbjCNMf6hOXGf99xhNxIb6E@2PGUe7OxJdyf59xpLuRLi/p/pxxtLvRLk/tPs/zK454N@LlKd59zzjq3ainU73P8/yKIx8N5YdO@e754m/0S@inU797vvmEfgn9bOp3z1ef0C@hn0397vnuE/ol9LOp3z1ffkK/hH72uctPm0Os3/76j3/8069fR73yuYfP…
@dzaima state is which switch case it's about to go into; f(x,w) where w is null, x is a smallish mixed array, and f is my least favourite function, the mysterious c(); param($x,$w) &$c (@($r,$x,$w)+$v)
or maybe that's the one before; which starts executing a new VM with $p at 8579
no that's it; new vm, new stack, bytecode[8579] is instruction state 21, why isn't that happening and printing in the javascript one
They're both calling a derived function and ending up in different places.
Which probably points to some combinator implementation being wrong, but it still shouldn't be possible to run out of stack if the bytecode and instruction implementations are correct.
@TessellatingHeckler These are functions defined pretty close together in some parent block, I think. There's probably control logic and it's choosing the wrong one.
updated, with expected effect on stack size of each instruction: https://dzaima.github.io/paste/#0jP1Bsu06sqYH9msUt58dAu4OuL9qxYuIa2pU5k17KQ1AlZXqVENlqezUBMrUrgFoCpqDhqKRiPx4ztokgUVHNN4LC/OzF4kfBBwfHD/@@M//7b/@8cf//D/9T//Lf/lvf/wv/@1//M//7z/@@OP/@f/9b//lP//P/6//sv/X//pf/j//9f@2//8/tuP//Lvt/77/t//z//f/L8f/8ucf2/H/j//848//8I8/CoH8T/@u7oFlDzz@WYk/Pv/5t3/@9/@BsEqYXP5esT@27def/H/89fe/9p88/6IQ2n79xeMflkao/Ar993uoEKqExh5a91D5CdVLqBJqR2Q5nlP2UP0JtUuoEdoItT1U91D7CW2X0EZoJ9T3UNtD209ov4R2Qp12Knto20P7T6hfQp3QIFT30L6H@k9oXELjCC0boX0P9T00fkL/dgktG7EFCQ5N49Bg@8T@6zUWEUoldteroFf5xP79GluJFWJ3wcoh2PFPf8X@4xq…
@dzaima (why is it that hardware is register based, software language VMs are most often stack based, but people hate Forth as a stack-based language to use?)
@TessellatingHeckler registers are have a constant size, and the CPU has a constant size, so that's a match; VMs don't need to have a constant size and may target platforms with varying register counts, so it's better to leave register allocation to the target; Stack-based languages are probably hard to use for actual humans
heh, a reason stack-based is bad is shared between CPUs and humans - you need to remember an arbitrary amount of data (for humans, though, a bigger factor is the fact that the data isn't labeled)
@TessellatingHeckler so from that you backtrack why it's 0 instead of 1
@TessellatingHeckler Not very related; probably l just has the wrong value.
@TessellatingHeckler Can you generate the runtime bytecode with cjs.bqn? What I did at this point was usually just to truncate it and test results of some of the functions it defines.
that (l value) comes from `l←≠v←𝕩` and `≠` comes from `(0<=)◶⟨1⋄0⊑≢⟩` and `◶ ← {𝕨((𝕨𝔽𝕩)⊑𝕘){𝔽}𝕩}`; of those `⊑` is a simple `$x[$w]` lookup we've just seen, statement separators work, variable passthrough we tested earlier, trains are untested, and `≢` is `{param($x,$w) &$list $x.sh}` which is untested but simple;
I can try but "dzaima: @Marshall can't even run cjs on that old commit :|" suggests it's not going to work
Actually we can probably just jump ahead to using the current bytecode. I don't think there are any new instructions, so you can ignore any changes to the bytecode interpreter and just update the provided functions.
Which I think you can do after testing the runtime: the only change to behavior is support for affine characters and I don't think r.bqn uses those.
@dzaima Yes, that has to change, but it's cleaner now and should make testing easier.
To be sure cjs.bqn works right on a shorter r.bqn you have to add ⟨IsArray,Type,Log,!,+,-,×,÷,⋆,⌊=,≤,≢,⥊,⊑,↕,⌜,`,⊘⟩ to the beginning to make sure every provided value is used. Then on the last line of src/pr.bqn change impl∾<"⟨"∾"⟩"∾˜1↓⥊","⊸∾˘chr to just impl so it doesn't try to export all the primitives (which probably aren't defined yet) and instead returns the result of the last line.
Add GroupLen and GroupOrd to that list: the comment in r.bqn is out of date.
@code_report I just watched Maximum Nesting Depth of the Parentheses. I would use {⌈/+\-⌿'()'∘.=⍵} but if you want to start by filtering away non-parens, you can use ⍵∩'()' instead of (⍵∊'()')/⍵. Also, to subtract the complement, you can use -∘~⍨ instead of (⊣-~)
