Another implementation of an interpreter + assembler + debugger

[voliva]

Would it be possible to add my wspace interpreter + asseembler + debugger into the list? I didn't realise there were so many when I got to play with it 😅

Developed with Typescript, and the debugger in React. It's public in my github https://github.com/voliva/wsa and published in github pages: https://voliva.github.io/wsa/

Unique features from my implementation:

• The debugger has step in, out and over function calls.
• Can set breakpoints over the code.
• debugger instruction to add a breakpoint from code (only active through a dev flag, by default the assembler builds a v0.3-compatible output)
• A stdlib (so far only memory and io) adds memory allocation through malloc and a heap-based stack to store local variables.

[thaliaarchi]

Thanks for showing! First of all, sorry for the delay. I've now pushed commits adding your project to the corpus as typescript/voliva-wsa. Take a look and let me know what you think.

The only thing I'm not satisfied with is building it in Docker. It's a problem shared with all the other TypeScript and JavaScript projects in the corpus. I haven't regularly written JS/TS in years now, so I haven't kept up with the fragmented ecosystem and don't know what the best build tools are. With the Docker build automation (in the Earthfiles), I aim to build each project to a self-contained form for portability—usually a static binary—so they can be moved to a Docker image without the dependencies. This is important with the sheer scale of the corpus and the goal to combine all 366 projects into one image.

The current build script for yours is just npm install && npm build. It works, but necessitates keeping around a huge node_modules directory. Do you know of a bundler that can trim that down and works drop-in for (most) any JS/TS projects? My golden standard would be one that performs dead code elimination on dependencies, but doesn't alter the formatting, so its still readable. I've tried messing with bundlers for this a couple of times in the past, but haven't had success.

---

Your project is pretty interesting: not that many projects define their own extension instructions and there are far fewer assemblers than interpreters or disassemblers. Surprisingly no one else had used sequences in the arithmetic prefix, so your or, not, and and do not conflict with other non-standard extensions, but both encodings of debugger conflict with several.

You have a nice little bitwise library and I like that you have versions both with your extensions and with 0.3 instructions. I have a soft spot for implementing bitwise ops in Whitespace. Few people dare to write complex programs in Whitespace (I wonder why :) ). It reminds me of someone who wrote El Gamal encryption and decryption in Whitespace, as well as a suite of functions, including bitwise. In my bitwise library, I avoided any heap side effects, so that it is easy for my compilers to analyze and it can remove all the stack instructions when converting to registers.

As for the assembler, I've been analyzing every Whitespace assembly dialect in the Whitespace Corpus, with the aim of making a universal assembler. I hadn't thought about it in a while, but last week, after documenting your dialect, I had a key insight into building an interoperable concrete syntax tree for Whitespace assembly and ended up building omniwsa. It's already quite promising and can handle both the Burghard and Palaiologos dialects so far in the same CST, with considerations made for many others.

Since your wsa dialect is line-oriented and quite similar to Burghard wsa, I already built out most of the features I'd need and it wouldn't be very difficult to add. The only issue is then my style of implementing with pedantic bug-for-bug compatibility :). In reimplementing a language, I effectively standardize the behavior and I found a couple of bugs in your assembler which would be slightly annoying to reimplement. For example, DİV works as a mnemonic for div when your locale is Turkish, but not otherwise. Also, the error handling for arguments is somewhat weak. If you're open to it, I'll probably send a PR with fixes when I revisit it, unless you've fixed it before then.

---

I'm using the name “voliva” for your dialect. If you'd prefer a different name to be used, let me know. I didn't use the name of your project, because ”WSA” is not very brand-able.

I'd recommend you choose a license for your project. I couldn't find one noted.

[voliva]

Hey, thanks a lot for looking into this!

You raise a good point about node_modules - that's mostly for the UI, which uses react, etc. but the interpreter + assembler + cli uses only a small subset (commander for command parsing, and then the build tools). I'm thinking I could try and break it down into 2 different packages so the UI stays as a separate one.

You have a nice little bitwise library and I like that you have versions both with your extensions and with 0.3 instructions. I have a soft spot for implementing bitwise ops in Whitespace. Few people dare to write complex programs in Whitespace (I wonder why :) )

Yes, I really wanted to target 0.3, and felt like I could add some extra instructions for debugging + bitwise. The bitwise ones is because I'm actually trying to implement keccak hashing with whitespace: https://github.com/voliva/wsa/blob/keccak/keccak.wsa - I have a bug somewhere that's not giving the correct output, I still need to debug it. But it was a bit too slow when using the bitwise library, so having those few basic operators made a big difference. keccak won't be part of the "standard library" of course, I just have it currently unorganised in a branch here :'D

voliva as a name for the dialect is fine, thank you! I'll also add in the license, I'm thinking MIT.

[thaliaarchi]

Closing as resolved, as it had been added to the Corpus.