wat-compiler VS thislang

For some time I've been fascinated by the codebase of a small WAT compiler written in JavaScript.

https://github.com/stagas/wat-compiler/blob/main/story.txt

And I mean "small" as a real complement to how readable the entire compiler is. It's also been a great way to appreciate the design of the WASM text format and WASM overall. It's not a Lisp but has a similar feel to it.

I've been meaning to get more fluent at writing WAT directly, not for any practical purpose but just for pleasure of it. I could see myself gradually building up some abstractions to help me deveolp larger programs, perhaps a slightly higher-level language.

I was also disappointed that this isn't included in the browsers given that it was designed to be very simple to parse and compile. So I tried as an exercise to build such a compiler[0] and indeed it was much easier than I expected (with a few shortcuts of course, being a POC). It is just 5kb gzipped and it compiles to binary most of the WAT code out there and also quite fast, just a few ms. That said, I think writing WAT by hand is only helpful for very small critical hot code, anything more complex and IMO you need an abstraction of some sort.

[0]: https://github.com/stagas/wel

Method calls are nothing special, just calls which have the form .(). For example: const foo = { bar: function () { console.log(this); } }; foo.bar(); Enter fullscreen mode Exit fullscreen mode For method calls, this gets set to the object from which the method was called. Again, functions don't matter* for this, just the calls. function foo() { console.log(this); } let x = { bar: foo }; foo(); // Window x.bar(); // x let baz = x.bar; baz(); // Window Enter fullscreen mode Exit fullscreen mode Even baz will print Window. It's not a method call, it doesn't follow the method call format! 3. Constructor calls Or new calls (are calls too I suppose). In that case this gets set to the empty object {}. function Foo() { console.log(this); } new Foo(); // {} Foo(); // Window let x = { foo: Foo }; x.foo(); // x Enter fullscreen mode Exit fullscreen mode That's pretty much all there is to it......... ........or is it?! I apologize for this Remember how I told you this is all about function calls, not the functions themselves? Well, I lied. Ok look, let me remind you once again: They made javascript in 10 days! The this rules we've discussed above, they are a bit limiting. So there's three* ways you can override these rules. * don't you dare even mention apply 1. call The special call method on functions allows you to pass your own custom value of this to a function call (or the call's scope I should say). function foo() { console.log(this); } foo.call({ a: 42 }); // { a: 42 } Enter fullscreen mode Exit fullscreen mode 2. bind bind is another builtin method on functions. Much like call it too allows you to pass a custom value for this to the function call. Except unlike call, bind doesn't immediately call the function. It instead returns a special 'bound' functions. function foo() { console.log(this); } let bar = foo.bind({ a: 42 }); foo(); // Window bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode 3. Arrow functions Arrow functions are the third way to override the call rules for this described previously. Arrow functions capture the this from the function scope in which they are created. function foo() { const bar = () => { console.log(this); }; return bar; } let bar = foo.call({ a: 42 }); bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode So they're essentially the same as defining a normal function but then also binding it. // achieves the same effect function foo() { const bar = (function () { console.log(this); }).bind(this); return bar; } let bar = foo.call({ a: 42 }); bar(); // { a: 42 } Enter fullscreen mode Exit fullscreen mode In summary Yes, no pun in the heading this time (oops). The key takeaways are this: In JS this is associated with the current function scope, and since function scopes are associated with functions calls -- this is associated with calls. Those are the rules but they can be overridden. That is the reason why people are often confused when passing functions referencing this to callbacks. It's also why you were told to use arrow functions if you need to pass them to callbacks. I too was confused about this for a long time. Instead of taking the more sensible approach of reading an article such as this one, I instead decided to implement my own javascript. I wrote a subset of javascript. In that subset of javascript. If you want to go down that rabbit hole, then check out the repo: https://github.com/BlueBlazin/thislang If you want more posts on other javascript or computing related topics let me know on twitter: https://twitter.com/suicuneblue