Topic proposal: A transpiler to JavaScript

[abhin4v]

Topic proposal: A transpiler to JavaScript

I propose a new topic for the book: A transpiler to JavaScript. The idea to write a transpiler (a source-to-source compiler) for a simple imperative programming language to JavaScript (JS). This new language — that I call KahwahScript[^1] or KS for short — is similar to JS in syntax, but has fewer constructs and simpler/different semantics.

Some examples of different semantics:

• Dynamically typed like JS, but strongly typed like Python.
• Variable declaration requires initialization.
• Only false and null are falsey.
• All variables are lexically scoped.
• Functions have fixed arity.
• No undefined.

Some examples of missing constructs:

• No anonymous functions.
• No for loops, only while loops.
• Only number, boolean, string and function types.
• No classes or objects.

In terms of code, we’ll need to write a Tokenizer, a Parser, a Translator and a CodeGenerator. This can be structured as two chapters, first for the first two components, and second of the last two.

Alternatively, we can make writing the Tokenizer and Parser an exercise for the readers while providing hints for their implementations, because there may be other chapters about parsing. In such case, we can have only one chapter that focuses on translation of KS to JS, and code generation.

We limit the scope to these components only, and leave the rest of the work as exercises for the readers. This may include:

• Writing an interpreter for KS.
• Using the interpreter to test the transpiler implementation.
• Writing a REPL for KS.
• Enriching the language/transpiler and the runtime to enable writing a self-hosted KS-to-JS transpiler.

The main takeaways from the chapter(s) will be:

• Writing an AST-to-AST translation based compiler.
• Learning the nuances of JS, and work around them to maintain the semantics of the source language.
• Optionally, if we choose to have a chapter on tokenization and parsing, how to use parser combinators to write a tokenizer and a recursive descent parser.

The main potential complication that I see is, the readers may have to learn too much about the idiosyncrasies of JS.

For a proof of this concept, I’ve already written an implementation of the transpiler in Haskell.

[^1]: Kahwah is a traditional preparation of green tea consumed in the North Indian subcontinent, and in this case, a word play on Java (a coffee).

[gvwilson]

Hi @abhin4v - thank you for suggesting this, but one of our guidelines is that each topic (chapter) should be teachable in one hour, and this feels much bigger than that. We already have people working on parsers; is there some other subset of this idea that you could carve out? Thanks - @gvwilson

[Anton-4]

one of our guidelines is that each topic (chapter) should be teachable in one hour, and this feels much bigger than that.

It does seem possible to make the language very simple. This would make the tokenizer, parser, translator and code generator very simple as well. Thereby making it teachable in one hour.

[gvwilson]

I'm still nervous:

1. Introducing another language (albeit a mini-language).
2. We already have chapters on parsing.
3. The functional language community has a long history of focusing on language processors; perhaps the biggest objective of this book is to show that they can be used for other kinds of applications.

@abhin4v would you consider implementing the VM from https://third-bit.com/sdxpy/vm/ instead? Showing how to do things that most people consider very stateful (VM, editor) in a PF language would be cool, and the comparison with the Python and JavaScript versions (https://third-bit.com/sdxjs/virtual-machine/ for the latter) would be very cool.