{"action":"created","issue":{"url":"https://api.github.com/repos/WebAssembly/design/issues/697","repository_url":"https://api.github.com/repos/WebAssembly/design","labels_url":"https://api.github.com/repos/WebAssembly/design/issues/697/labels{/name}","comments_url":"https://api.github.com/repos/WebAssembly/design/issues/697/comments","events_url":"https://api.github.com/repos/WebAssembly/design/issues/697/events","html_url":"https://github.com/WebAssembly/design/issues/697","id":156420542,"number":697,"title":"LES as the text format","user":{"login":"qwertie","id":720717,"avatar_url":"https://avatars.githubusercontent.com/u/720717?v=3","gravatar_id":"","url":"https://api.github.com/users/qwertie","html_url":"https://github.com/qwertie","followers_url":"https://api.github.com/users/qwertie/followers","following_url":"https://api.github.com/users/qwertie/following{/other_user}","gists_url":"https://api.github.com/users/qwertie/gists{/gist_id}","starred_url":"https://api.github.com/users/qwertie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qwertie/subscriptions","organizations_url":"https://api.github.com/users/qwertie/orgs","repos_url":"https://api.github.com/users/qwertie/repos","events_url":"https://api.github.com/users/qwertie/events{/privacy}","received_events_url":"https://api.github.com/users/qwertie/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2016-05-24T05:04:46Z","updated_at":"2016-06-14T00:39:51Z","closed_at":null,"body":"I would like to propose the next version of [LES](http://loyc.net/les/) to be used as the WebAssembly text format. More specifically:\r\n\r\n - I propose that the Wasm text format be _compatible_ with the next version of [LES](http://loyc.net/les), in the sense of being a subset of it, such that a \"full\" LES parser would not reject anything that is valid Wasm text.\r\n\r\n- For the MVP, those that want to parse Wasm text will be able to choose whether to use a custom parser dedicated to Wasm or a generic LES parser.\r\n\r\n- My proposed syntax (link at bottom) _is not_ compatible with the current LES specification, but LES is in beta and can still be tweaked to Wasm's needs. Based on the Wasm text format, a third version of LES (LESv3) will be drafted before the end of 2016.\r\n\r\nThis gives the CG some freedom to make _some_ changes to LES and not others. Specifically, any elements that make sense _only_ in WebAssembly (e.g. keywords for wasm opcodes) would not be permitted, but changes such as tweaks to operator precedence, handling of semicolons, the grammar of LES \"superexpressions\", or the name used for \"infinity\", are fine.\r\n\r\nWhy use LES for WebAssembly?\r\n----------------------------\r\n\r\n- **Fewer parsers will be needed in the future**: in today's world, every new language needs a new parser to be written, bikeshedded, and specified from scratch. While LES is not sufficient for all languages, it will be enough for some (and in particular it is sufficient for Wasm, which has weaker reasons than most languages to use a custom grammar); being part of Wasm encourages use of LES elsewhere (_edit_: consider DSLs and advanced search boxes. I wrote some GIS software that did formulas & searches, so used an ANTLR-based parser. But why are people still writing custom parsers for expressions? There should be a standard - so here it is.)\r\n\r\n- More importanty, **learning curves decrease**: imagine a future world in which a user has _already_ used LES as a programming language or a data language. She wants to write Wasm assembly for the first time, and _it's easier to learn_, because the syntax is already familiar. She may have many concepts to learn regarding the _semantics_ of Wasm, but at least the syntax is easy. Conversely, she may learn Wasm first and another LES-based language later. Either way, the same benefit accrues.\r\n\r\n    By analogy we may compare LES with punctuation and grammar in natural language. When I learn a new language, I have a lot of new words to learn, of course. Luckily, most languages share the same meaning for punctuation: I don't have to re-learn a new version of the comma, dash, parentheses and so on. But grammar is another story: it always varies between languages, sometimes dramatically. Similarly, different programming languages will always vary in _concepts_ and _idioms_, but it isn't necessary for every language to also have different punctuation and grammar - and even most of the words could stay the same. LES is the only language (AFAIK) that takes the kind of standardization you see in s-expressions and applies it in the Algol-family space.\r\n\r\n- **Various things become easier**: let's say I want to analyze some C++ code... from within my Rust or Python code. But all the C++ parsers are written in C/C++! See the problem? We don't have easy ways to cross arbitrary language barriers today. Now imagine a world after Wasm MVP: people will want to process Wasm text (and binaries) from many different languages. Because it _is_ hard to cross language barriers, the way this will happen is that many different people will write their own readers and writers for their language of choice. If the text format _isn't_ something generic like LES, the story ends here with folks merrily parsing Wasm. But if the format is generic, the results are more interesting:\r\n\r\n    - LES typically represents data more compactly than XML and JSON (and I assert it's \r\n      easier to parse _correctly_ than YAML, and is built atop better primitives), so \r\n      some people will start using it as a data format. It's especially good for data with\r\n      embedded code (e.g. build systems). Network effects are crucial here: no one wants \r\n      to use an obscure data format, so it _must_ be used first in a major standard like \r\n      WebAssembly.\r\n    - LES and Loyc trees were designed to help with a variety of tasks related to \r\n      building compilers, converting code between languages, and bridging language \r\n      barriers (both human and machine). Some compilers today can dump their AST in \r\n      an XML format, which can allow a program in a different language to pick up that \r\n      code and do something with it. But LES is far more compact and just better at \r\n      representing code than XML is. So LES makes it easier to talk about, work with, \r\n      and reason about syntax trees in the same way s-expressions do. However, LES is\r\n      completely unknown today. WebAssembly's role here (should you choose to accept \r\n      it) would be to create awareness of LES and cause people to write LES parsers \r\n      for numerous languages. This may lead more people to get involved in writing \r\n      language-processing tools than in the world we have now, where you're lucky if \r\n      you can even get an XML representation of a given language. This in turn should \r\n      facilitate the creation of interoperability and code-conversion tools, \r\n      ultimately improving interoperability between languages.\r\n    - On a personal note, I want to build a library for converting code between \r\n      programming languages, and I want to use WebAssembly semantics as a \"common core\"\r\n      for such tasks. I expect this to be easier to do if WebAssembly uses LES.\r\n\r\nI'm concerned that some would simply say \"this is out of scope\". But I don't think this will strain the dev process. So why not try it? Others might argue along the lines of \"we shouldn't use LES because I really prefer `foo:` instead of `:foo` for labels.\" I would urge those people to look at the bigger picture. Thanks for your consideration!\r\n\r\nWhat does Wasm+LES look like?\r\n---------------------------------\r\n\r\nTo show you how Wasm could be encoded in LES, I have created a [PR to show how Dan Gohman's strawman would need to change](https://github.com/sunfishcode/design/pull/3) to be LES-compatible.\r\n"},"comment":{"url":"https://api.github.com/repos/WebAssembly/design/issues/comments/225749771","html_url":"https://github.com/WebAssembly/design/issues/697#issuecomment-225749771","issue_url":"https://api.github.com/repos/WebAssembly/design/issues/697","id":225749771,"user":{"login":"JSStats","id":11826073,"avatar_url":"https://avatars.githubusercontent.com/u/11826073?v=3","gravatar_id":"","url":"https://api.github.com/users/JSStats","html_url":"https://github.com/JSStats","followers_url":"https://api.github.com/users/JSStats/followers","following_url":"https://api.github.com/users/JSStats/following{/other_user}","gists_url":"https://api.github.com/users/JSStats/gists{/gist_id}","starred_url":"https://api.github.com/users/JSStats/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JSStats/subscriptions","organizations_url":"https://api.github.com/users/JSStats/orgs","repos_url":"https://api.github.com/users/JSStats/repos","events_url":"https://api.github.com/users/JSStats/events{/privacy}","received_events_url":"https://api.github.com/users/JSStats/received_events","type":"User","site_admin":false},"created_at":"2016-06-14T00:39:51Z","updated_at":"2016-06-14T00:39:51Z","body":"Glad someone is exploring this. It still does not seem to have the type inference so how can expressions work as well without a change to the binary encoding?"}}
{"actor":{"display_login":"JSStats"}}