[vidarh]

The problem is that I'm not talking about markup. Markup - unless it's so lightweight as to be near unnoticeable is not a solution. Unless every application you're transferring it via supports CSTML, the representation needs to be as compact and readable as a regular programming language.

To take your example, pretty much anything longer than [1, true, "3"] is a non-starter if someone is pasting it into Slack, or sending an e-mail. The CSTML representation isn't readable to them, and would take additional steps on both sides vs. just writing the source representation. I'm not going to tell people how to do something by writing it into some other tool and pasting some large blob into Slack or my e-mail client and expect the recipient to reverse the process.

That is the problem space. How you represent that as an AST isn't the problem - that's easy. How you represent it in a way that everyone can read and write and that "passes seamlessly" via existing tools is the problem.

(I must also admit that I think the choice of serialization format for CSTML is utterly baffling and feels like it adds a lot of NIH)

[conartist6]

We're using markup to communicate right now and it's the overhead is small enough to be unnoticeable.

Try copy and pasting some HTML-formatted text from this page into your paste buffer.

I assure you that what goes into the buffer is HTML. You can verify this because if you paste the text into an HTML-embedding WYSIWYG editor (such as an HTML email composer) the formatting will be preserved. But if you paste the content of the same HTML buffer into VSCode, notice that you don't get the raw HTML but rather the textual content that was embedded in that HTML.

[vidarh]

Now try pasting it into your terminal, or any of a large number of other tools that doesn't support HTML.

Now try doing the same with CSTML, in applications that so support HTML.

Now consider how little that markup contributed to the semantics of the text here - most of it can be stripped and the text retains it's meaning.

Then consider how long it took for HTML to percolate through these applications despite HTML - unlike CSTML- having universal utility.

And here's the thing: As someone with a history of writing compilers, parsers, language tools over 30+ years, CSTML is too verbose for me to want to use even for tooling. It's way too low level even as an internal representation for tooling.

It also still doesn't help: You still will need a compact textual representation anyway so people can represent it in contexts where the tooling doesn't exist, or can't exist, such as paper and handwriting, and speech.

All I can do is encourage you to try. If you succeed, great, and if not you will understand the difficulties involved.

I've tried the custom syntax representation (though I used XML which saved me from writing a custom parser) - it turned out to just be an obnoxious detour. I tried syntax aimed at removing ambiguity in round-trips, and it sort of worked but got too verbose. I tried a purely visual approach, and hence why I'm so insistent you need to be able to roundtrip to text. I spent years trying things and looking at others attempts.

I'd love to be wrong, but I very much don't expect any big breakthroughs in this area in decades - the attempts I keep seeing keep repeating all the same mistakes with few signs of lessons learned.

[conartist6]

Sorry maybe I wasn't clear VSCode is an application which doesn't support HTML embedding. It's no different than pasting in to Notepad, or a web browser text input. Did you actually try it? Did you notice that the HTML internal to the paste snippet didn't appear and ruin your day, no matter what application you pasted to? I was expecting you to see that only in the HTML email editor would you find any sign that there had been embedded formatting data.