Comments: LESv3 proposal summary about ecsharp

[tomjaguarpaw]

Wadler's Law strikes again!

[qwertie]

Actually, that's not true. The core WebAssembly team declined my requests to offer any opinions on the Wasm text format or LES, which is why I went to Reddit to ask for opinions. One conversation I had makes me think they are under too much of a time crunch right now to care about the text format.

[sunfishcode]

Speaking as someone who also proposed a text format which the group decided not to standardize at this time, the guidance going forward is: just build something, and see where it goes.

Stepping back though, I have some higher-level feedback which I hope is helpful. People are indeed busy, and giving helpful feedback to a complex situation takes effort.

Converting code between high-level programming languages can be a tricky endeavor, and it's not clear what role WebAssembly would play here, because it's so low-level. It seems to be unsuitable as an intermediate language when translating between high-level languages: lowering is often a straightforward thing to do, but "raising" is often not. Perhaps if WebAssembly used LES, it would save you the work of translating code from your own ASTs into WebAssembly when you want to run it. However, that seems like a small task, compared to the much larger tasks that would seem to be implied by the problems you're taking about.

A theme that seems to me to run through LES is that there are some ideas about solving some really big problems here, but that the specifics seem to me to focus on syntax a little too much, without enough acknowledging other significant challenges that would be involved, and without a clear demonstration that the syntax part would even scale up. If diverse languages are made to share a common syntax, will it make them easier to learn and read, or harder because they now just have to express the same ideas at a different layer of the system? A single solution for a set of problems can reduce duplicated work of having multiple solutions, but it can also create additional work by forcing the constraints of each problem onto each other. As an example, your blog post here lays out several awkward syntactic contortions and open questions, which makes me skeptical.

I recommend just building the system you want to build. Use your own syntax, your own data structures, and show people how cool it is. Unfamiliar syntax is an obstacle, but it's surmountable if there are cool things on the other side.

[qwertie]

@sunfishcode Welcome! Thank you so much for giving your feedback.

the specifics seem to me to focus on syntax a little too much, without enough acknowledging other significant challenges that would be involved, and without a clear demonstration that the syntax part would even scale up

I suspect you're talking about Loyc in general, since LES is almost exclusively about syntax. For the general problems of interoperability and conversions between languages, I know that the majority of the challenges are not syntactic, and I have been thinking about those non-syntax problems for a long time, but haven't reached any firm conclusions yet, which is one reason I don't write about those problems often (another reason being that I expect no one to read what I wrote). I am sure, however, that any solution will involve a lot of humans looking at code trees and talking about code trees (not only ASTs), and I believe LES is a great tool for communicating code trees - whether in the front-end, middle-end or even the back-end. It's a win-win: easier to convert your middle-end IR tree to a Loyc tree than to invent a special ad-hoc text language for that, and easier for end-users to read code in a familiar language than an ad-hoc one. (for anyone reading this and thinking "just use s-exprs" - there is a good reason why none of the top 20 languages are based on them.).

So a major reason I want LES to be used in Wasm isn't about Wasm at all; it's about giving the world a "lingua franca" for syntax that is comfortable to more people, and desirable in more situations than s-expressions. It's about, for instance, thousands of DSLs out there that defined their own syntax from scratch, because there is no single commonly accepted syntax for "expressions". What characters are allowed in an identifier? What is an operator? What's a number and how do you parse one? How do you write multi-line strings? What are the precedences of the operators? Some applications will always need their own separate parsers and printers, each individually documented and tested, but I'd wager at least half of them can just use LES, and many of the rest could use LES as a starting point or baseline.

But what does that have to do with Wasm? Admittedly, my reasons are selfish (although I quit my job to work on this and I have no current nor future income streams [re: Loyc], I live in a 3rd-world country, and the AC is off right now to save money on electricity, so how selfish am I really?). Almost no one knows about LES, and Wasm is an ideal opportunity to increase awareness of it. Plus, if Wasm uses LES then inevitably someone will write an LES parser for every major programming language. That would help a lot, because you're right: I focus on syntax too much, and I really want to shift my focus to semantics and let others write parsers for once.

If LES is chosen for Wasm I think it will help with programming language conversions, but not directly, because as you said, "raising" from WebAssembly to high-level languages is not straightforward. So what's the point? My idea - and it would help a ton if I could build a community to help develop this goal - is to develop a "high-level WebAssembly", analogous to the CLI/CLR, which starts from WebAssembly's AST form (the one binaryen plans to use) and builds higher-level constructs (e.g. structures, classes, and perhaps Rust-style memory safety) on top, using LES's natural extensibility (this can be built without using LES for Wasm, of course, but pedagogically it's best to maximize similarity between HL Wasm and ordinary "LL" Wasm). If one or more major languages can be convinced to target this HL Wasm instead of (or in addition to) LL Wasm, it would be a much better basis for both cross-language interoperability and for doing conversions between languages.

So the biggest issue to me is about how to build an OSS community around interoperability and language conversion - WebAssembly provides a kernel around which to organize such a community, it provides publicity, and any similarities between HL-Wasm and LL-Wasm (LES + same basic opcodes) will help people to learn both technologies. (And for anyone else reading this and thinking ".NET", I'd point out .NET cannot support some programming languages such as D, at least not performantly or in a first-class way, and see here - Wasm offers a new opportunity to get it right.)

And if HL Wasm exists, for some features it may be better strategy to prototype them in HL Wasm before baking them into the browser. This is better than letting each individual compiler implement such feature "polyfills" in its own way, because only the HL Wasm community would care about balancing the needs of all languages.

your blog post here lays out several awkward syntactic contortions

Several? I didn't think it was that bad, but this is why feedback is so important to me. I need specific criticisms so I can try to address them. The clearest signal in the survey so far, by the way, is that people aren't happy with the "juxtaposition" operator, so I'm about to drop it. I'm also switching to newlines-as-terminators.

One more thing, @kripken recommended implementing LES as a browser extension, but does Firefox have a debugger API - or at least an API for getting the original Wasm module as raw bytes?

[qwertie]

This did not end well.