-
Notifications
You must be signed in to change notification settings - Fork 0
Roadmap & Status
When introducing a novel language, the project must also develop an ecosystem around the language that is comprehensive enough to permit adoption. People obviously have different requirements, so it is difficult to know exactly when an ecosystem is mature enough for early adoption, or when it is production ready.
This document contains a loose roadmap, broken into sections that each cover a specific aspect of the project, with a description of the priority and current status of each aspect.
This document will be regularly updated as the project matures, allowing you to assess the readiness of the project, based on your own requirements.
The design of the language is the most important part of the project, and is the most mature.
While the syntax is unconventional, a lot of time has been spent eliminating every inconsistency and corner-case to endow the grammar with an internal elegance of its own.
There are some planned features that will make the language more convenient (like allowing a component to be defined and exported in a single statement, for example), and it is important to support future WebAssembly standards that might require substantial extensions to the grammar. Consequently, special consideration was given to ensuring that every aspect of the design is readily extensible.
The initial language implementation has been published.
Everything in the latest version of the WebAssembly Specification has been implemented, except SIMD, which has been designed (more or less), and will be implemented soon. Some proposals have also been implemented, including Threads & Atomics.
User-friendly debugging has always been a high priority for the project, and the assembler goes to unusual lengths to provide the most helpful and specific messages it possibly can for syntax errors. This complements the DWARF implementation (which will handle runtime errors) to provide a debugging experience more akin to high level programming.
The assembler itself is free of known bugs (though there is currently no test suite). Languages must be correct, so fixing bugs will always have absolute priority over every other aspect of the project, whenever one or more bugs are known to exist.
An assembly grammar naturally requires far less documentation than an abstract programming language, so it is possible to properly document the language with a crashcourse (covering all of the essentials) and a wiki (covering everything else).
Note: The project may still publish auxiliary documentation (the grammar cheatsheet, for example), that summarizes information that is also available in the crashcourse or wiki.
The first edit of The PHANTASM Crashcourse is complete, and available as a PDF. It will be ported to the Web at some point.
The wiki only has a handful of articles currently. However (alongside the crashcourse), the wiki already includes everything required to begin using the language.
Preliminary work on the DWARF implementation has begun, but the DWARF for WebAssembly spec needs extending slightly to support languages like WAT and PHANTASM. I'm optimistic this will be fixed soon.
Once the DWARF spec is updated, and our implementation is complete, it will be possible to debug PHANTASM modules in DevTools, with source-mapped runtime errors, breakpoints, introspection et cetera.
Note: The DWARF implementation is important, as PHANTASM is a source language. It it used to directly author and debug programs. This differs from WAT, which was designed for disassembling and examining WebAssembly binaries (when the source is unavailable).
Having a comprehensive test suite is obviously an important requirement. The plan was to do the DWARF implementation first, but given the issue with the spec, the test suite is currently the highest priority for the project.
While the availability of extensions for popular text editors and IDEs is important for adoption, the extensions should not be part of the PHANTASM codebase. They are beyond the scope of a language implementation.
The current plan is to develop an extension for VS Code (which also runs in the browser), and publish the extension through the VS Code Marketplace. The extension will be maintained as a separate project.
Note: Work on the extension has started, but it currently only implements syntax highlighting, and even that has a (minor) bug. Once the syntax highlighter works correctly (which should be soon), the extension will be tidied up and published in the Marketplace, then iterated on to improve PHANTASM support in VS Code.
Support for other editors and IDEs is not currently planned, though it would be valuable to have (assuming there was somebody to maintain each extension), so this may change over time.
The author is a web developer who uses Python on the server, so has very little experience with Node JS. However, it would be silly to publish an assembler that can only be used in the browser, so an official PHANTASM package for Node JS will be published shortly.
This document sets out a loose roadmap for developing the various requirements of the project. However, the existing code, docs et cetera will still be iterated on and improved as new requirements are developed.
It is also necessary to continually use PHANTASM to develop small test projects to ensure that everything works well in practice.
A PHANTASM playground will be developed too. It was largely implemented before the work started on the assembler, so would not take much work to put online, but there are many higher priorities at the moment.
The grammar has been figured out, and a useful version of the language has been implemented. Everything has also been documented.
The DWARF implementation is waiting on an update to the official spec, and the test suite will be completed next. Packages for VS Code and Node JS will also be published soon.