`walt-sugar` package

Feature Request

Overview

walt started as a Javascript-like “assembler” language for WebAssembly, in the way that it would only expose the WebAssembly bytecode as Javascript functions, allowing to program low-level code using a high-level language (sort-of).

Over the time, it has started to get some discussions about sugar syntax and high-level features, like Strings or literal objects. These are nice additions to be able to use, but are abstraction layers that don’t directly map 1-to-1 to WebAssembly bytecodes. Since we are using here a lerna monorepo, I propose to split this sugar syntax and high-level features to a separate package walt-sugar to have both concepts isolated, implementing the high-level sugar using the low-level functions as building blocks. Alternatively, instead of separate the high level sugar, we could move out the low-level to a walt-assembler package that does only the 1-to-1 mapping of WebAssembly bytecode… or maybe both things, being walt-compiler just only a translator 😃

Impact

Medium. Need to create new packages and split code, but later concepts would be isolated and layered and easier to understand what’s WebAssembly core and what not.

Due Date

2018-04-03

[ballercat]

For anyone still following along, a major part of this effort has just been completed. Which is nice. It was an interesting challenge to modularize the compiler(at least the semantics parser for now) by feature. The core semantic parser is now completely split by feature and the compiler retained full feature parity.

All in all, this is/was a very good idea. This type of feature separation should pay off in the long term. Core features plus syntax-sugar(like closures) are all implemented as composable “plugins”. The nice benefit of this approach is that it makes the syntax infinitely extendable, very similar to how JS is extendable through Babel.

For this to be “complete” it’ll take a bunch of refactoring and moving of shared “parser utility” logic, plus ways to test syntax-sugar features in isolation etc. Not to mention the documenting all of the utils which used to be private to the compiler implementation + how to write a plugin.

Oh, and the changes would also require a major version bump to 1.0 (even though still alpha) as it’ll change the public APIs without being backwards compatible. This might be avoidable but unlikely.

Anywyas, good stuff.

[ballercat]

Yeah, maybe the problem here is to decide how to allow to do that integration…

Yup, the how is the difficult part 😃