@Adám In the AEIOU example here, shouldn't ⎕UCS[0,⍳64] be ⎕UCS 0,⍳64? I understand that the code-like fragments are not really code, but it gives the impression that ⎕UCS is a char array like ⎕AV, while it really isn't.
@Szewczyk Classic is a deprecated pre-Unicode legacy version missing some features, including script support. That's why it echoes input in the Debug pane on TIO.
it works! gave up on the StackMapTable stuff though so currently it's just saying it's java 5 https://dzaima.github.io/paste#0tVfbbuM2EH3XVxD2SwykskjdbG1dIGtk2y2yQdpcgKILGIxMO0oUyhBpx23R1z73b/oB/ZN@SUlatiSLlJ298EkmOTNnzgxnxgCA3iNZ4RT8@w90vllbdzhdkvM8z/II3NInmr1QsMJ5gu9TAjrrjgUAWP/319@@/KiLOjay5K4l1mJ5nyYxiFPMGHj706U9J9QBZM0JnTJwdnVh8yxLmf3j94QKmeeEZjlYkZwlGY2AI7fwY3XLG4q9WYrnLAInztpxEOyBs/F4cnX79uL9@FR9X99enf8s7vGHhE2U7Qh03RCYVr8vsfUlNiHFlguS78S8NinhQF850C8cSCgn@QzHRIg6p2CWkHS6@Xwm/CGT3@gUYM7z5H7J1S1rnFHGMeVgITRFkrkuBCNwy2eDPYvfJjTh36kbSH/jpHenjl39cQOv9G8Exio8tSU0HPIVdH0he4mfyRmd3vy2IDtZGAl…
the spec is indeed wonderful, and the jvm gives surprisingly pretty errors for things that practically never happen
@ngn i couldn't force myself to sleep before i had a single PUSH working, slept for maaybe 6 hours, and continued working on it pretty much instantly after waking up. :p
the generator currently is 12.5kb, 450loc (no dependencies except dzaima/BQN), but ÷10-x shows all the supported bytecodes
@ngn yeah, all manual bytecode & class structure generation; i'm obviously working on implementing the rest of the dzaima/BQN bytecodes, just saying that PUSH FN1C FN2C is all i've implemented currently
@dzaima The error-catching operator should be ⎊. I think there also needs to be a block-level catching syntax, but the operator is a nice shortcut for functions.
Main trouble with the block syntax is what information goes into it, and how to deal with multiple bodies. I'm thinking it should just be another body with a special header, and if it's placed after a body then it applies only to that one, but if it goes in front of all bodies it applies to the entire block.
@dzaima If you're working on primitives, could you make scalar (pointwise? atomic?) functions follow leading axis agreement like Each?
@Marshall i don't really see a need for >1 syntax for catching errors. It should already be rare enough (i imagine the only good usage of it would be for automated tests verifying that things that should error do error), and catching specifically what should error is imo better than the whole block
@dzaima But if you make it an operator, then you can only catch errors in functions. The idea with blocks is that you'd generally wrap a single expression in an immediate block in order to catch errors there.
@Marshall it'd require me finishing the transition from the old vectorization in Fun to Pervasion, but there are currently a couple built-ins that require extensions to that system; i guess i could implement it for the ones already moved
@Marshall i guess that's reasonable if you want to catch errors from anything anywhere, but i'm pretty happy with making catching errors difficult
@dzaima Yeah, that's a good point. I'll keep this in the back of my mind but relabel not doing anything about it as cautious consideration rather than procrastination.
@dzaima Cool, now I can remove some mysterious Eaches from leading.md.
Finally working on function/block support in the self-hosted compiler. I can now separate out the bytecode for each function despite generating it all together, and generate the DFND instructions to load them. Now I just need to detect their roles so I can call them appropriately, and create that nested bytecode structure.
@dzaima You could always require a list of bytecode sequences, with the first one assumed to be the result. Then you'd also need a list of type/immediateness pairs as well.
The biggest problem for me is that the functions don't share the same dfns tables. For objects I can reuse the table on every compilation even if not every element is used, but for blocks the recursive structure doesn't let me do that.
@Marshall i guess nothing's preventing just using the same byte[] for all inner dfns. i already have support for starting at an arbitrary point in it for headers
i guess i'll try doing that
(another thing to note is that •COMP doesn't allow creating headers/multiple blocks due to headers being tied directly to their tokens)
Could there be an external table of type/starting index pairs? That would be pretty easy to work with.
Where the possible types are immediate block, function, immediate 1-modifier, immediate 2-modifier, binding 1-modifier, and binding 2-modifier. Unless I'm forgetting something.
@Marshall that'd probably be how the •COMP interface would look like - a vector of types, and vectors of vectors (or possibly some other format), a vector per dfn with offsets for each header as the position in the bytecode where to start
@Marshall 6 types is right - 3 "main" types (function, 1-modifier, 2-modifier), and each with an immediate and non-immediate subtype
@dzaima right, a dfn is compiled at tokenize-time of the parent expression, which means i'd have to pass the mutable compiler structure around the tokenizer. Or i could just not and only expose this system for •COMP
body data pretty-printing: https://dzaima.github.io/paste/#0jVK9TsMwEN7zFEc3VIbYqVAxU0WJmNqq/KzI@ZOKaIOaLFVViYEB0RmFBXVgcV4C3iVPwCPgs2OalrTCSvzz@bvzfXcHAIeeD3O3WAl@5BWrnPHi@dODU7C/319f5J8znCSAi5rFonj8mstNdiunD5zeGF5kRbbEg7kXTbRZWH4chMwC2wXbBhxdt9cFWyNkjRCN0DVCJeLgh6MzHPbBsYJokqA3@UM6ewghArnz4mAmMRjHEx6MfAsNkpRPU4YP4SG8jxhEaq9kAWqGYvkEqNu4IAyC2baHtrES2pti0trHCDH3Tp0n0pKnMh@A4suM3HSktobXUKht0MH15QUcyIIYMqmQuSYfQzncHj1DhJwYZHh@1TOWtGKJ8hu7qc7/qa1NqkBq7N0lWp1MsQo9Sae/iKecMeC4UtU2mHvMltm21FZYkmZKHFRLPBqPw2DE03BXkbEr96UZe7Q@09myLtPY2prfNknoD2h3W6syrmrFd0q56MKSejd6dl@AeW2AzR3hCV0jUumF/lZ4zb/B5evgx…
Block support is up! Nested functions and modifiers seem to work well. No headers yet. And there are at least some bugs since (3⌊↕5)≡{i←0⋄r←{i+↩1⋄1+𝕩}⍟(↕4)𝕩⋄r∾i}0 is failing.
Wait, that's probably just because I don't have modified assignment.
Yes, it works when I expand the assignment and we're back at no known bugs.
