I don't see how WASM is that high level. It doesn't have types except numbers (ignoring reference types and the GC proposal), which makes it lower level than LLVM IR. The control flow constructs are also much closer to SSA form than anything viable for humans.

If you ever try to write WAT by hand you realize that it's very much a compilation target, not something you'd ever want to manually write.

Unlike LLVM, control flow is actually structured, no arbitrary jumps, functions, tables, real harvard separation of code and data.

The restriction to only number types, is more a byproduct of trying to keep the 1.0 spec as mvp as possible, and reference types are gonna be a big shift in that regard.

I mean compare these two. One is a (very low level) language, the other is (high level) assembly.

https://developer.mozilla.org/en-US/docs/WebAssembly/Referen...

https://mapping-high-level-constructs-to-llvm-ir.readthedocs...

> a small macro system for WAT, that bootstraps a slightly more highlevel lisp dialect

Lisp traditionally has immutable data structures and a garbage collector, in which case I would consider it more complicated than LO.

I would be very interested if it’s possible to create an extremely simple garbage collector or an ergonomic Lisp that isn’t garbage collected, but a solution doesn’t spring to mind.

A classic mark-and-sweep GC for a heap of uniform structs (like cons-pairs) can be implemented in a few lines of code. Garbage collection is not inescapably complicated, it just gets more challenging as you impose more constraints: multithreading, generations, compaction, minimizing bookkeeping overhead, etc.

While I'm a huge fan of immutable persistent datastructures, I don't think that they are a neccesity.

And linked lists with reference counting are really easy to do, and don't have any leaks if you don't allow cons cell abuse. (which would mess with immutablity anyways)

You could also do linear types like carp [0], or you could just do manual memory management.

I feel like most people will call something with macros and s-expressions, a reasonable, if brutalist, lisp.

0: https://github.com/carp-lang/Carp

> Lisp traditionally has immutable data structures

Can you provide a source for this? Common Lisp and its predecessors certainly do not have immutable data structures out of the box. The usual data structures are cons cells, lists (composed of cons cells anyway), vectors, and hash tables.

> I would be very interested if it’s possible to create an extremely simple garbage collector or an ergonomic Lisp that isn’t garbage collected, but a solution doesn’t spring to mind.

PreScheme immediately comes to mind for me as does ulisp. The latter in particular is designed for microcontrollers with limited memory.

That much be a very special kind of Lisp, given the amount of variations since the Lisp 1.5 Programmer's Manual came to be.

Pairs in Lisp are mutable, traditionally, and there are other mutable data types like vectors. For targeting wasm only there's no need to figure out a GC solution as that is something the host provides in wasm 2.0.

You could probably do something similar to what Roc is doing: https://www.roc-lang.org/

That was how it started actually, I wanted to make a superset of WAT. But then I switched to a more familiar C-like constructs and that gave me a big boost in productivity.

I think the superset of WAT idea is very viable and someone more comfortable with s-expressions should explore that for sure.

Thank you for your insights, again very cool project!

it would be assembly script, the most simple possible typed language to make scripts for wasm. its almost identical to js.

While that may be easy it's definitely not simpler than WAT.

https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...

Yes, this would be similar approach how Lisp Machines, and Interlisp, came to be.

Low level forms for systems programming, and then everything else was built on top of it.

Picking something like "An Incremental Approach to Compiler Construction", but instead of Scheme, stay in WAT and move from there, adding features.

http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf

Or stay in Scheme ;) https://spritely.institute/hoot/

Indeed.