Personally I'd rather see this class of problem solved at the language level [0] through strong typing of DSLs, rather than at the editor level. Nonetheless this is still an interesting approach.
If I understand correctly this is AST editor that has the feel of text editor. That's a thing I wanted to create for a long time. Although I wouldn't have dreamed for it to work with mixed languages.
I'm curious to see some example use cases which are practical. Yes you can embed SQL in Python in HTML, but I think it's pretty obvious that this not a great idea. Even more common examples such as embedding CSS in HTML seem fairly ill-advised.
Well, you would put SQL inside a string in Python. PyCharm/IntelliJ already recognize that: as I write execute("SELECT... ") it considers the string PostgreSQL and autocompletes among the table names in my project's database; and If I write ("SELECT foo FROM bar") if the bar table has no foo, it highlights foo just like it would a Python variable that was not defined.
Now interestingly when you are within that SQL string you can press Alt-Enter (the general key for some context sensitive magic) and open a new nested editor window with just the PostgreSQL fragment. Let's say that PostgreSQL fragment now itself embeds Python code again (now running server-side using PL/Python). Yep, you can tell it the string inside SQL is Python.. and open another window. I then added an XML string inside the Python inside SQL inside Python, however it wouldn't go any deeper. However it does give you the syntax highlighting and language-specific warnings in XML, PostgreSQL, Python within Postgresql and top level Python:
Beyond the first level however, I had to manually tell it that this string is Python.
One place would be the Aspen web framework which puts Python code, templates and JSON in a same file with its simplates concept [1].
Each language stays in a separate section so no mixing of logic and presentation, but no reason to separate them either, out of HTTP request/response handling context. An editor supporting this could make it easier to develop web apps with both static HTML and JS enabled browser.
Apparently Eco also supports visualization and IPython in some way (according to project changelog)[2]. That is very interesting, actually.
I think it solves a practical problem for HTML templates.
For example, React embeds HTML templates into JavaScript using JSX. Unlike most template languages that generate strings, their templates build a JavaScript tree structure without an intermediate string phase.
This is rather hard to do in a practical way without a language extension, since having a separate file for every tiny HTML template is unwieldy. Also, most alternatives involve building a shadow language [1] into the template language which isn't as elegant as writing code in whichever programming language you're already using.
First example that comes to mind is SQL inside Python (I'm actually doing this right now). Say, you've got a raw SQL query in your Django app. To a standard editor, the query is a simple string, however it's absolutely great to be able to mark this string as SQL, getting all the correct syntax highlighting and linting etc. PyCharm already does this, even going a step further, validating the DB schema along the way. Super useful!
Database stored procedures almost invariably involve writing Python (or whatever) inside of SQL/DDL. Database change management systems (e.g. Liquibase) will often involve writing chunks of SQL inside of XML/JSON/YAML. More generally, configuration files often involve string parameter values that are actually expressions in some subsystem or related system.
Sorry, good point. In my head I was thinking "except when using the native procedural language", but it appears I didn't get around to actually typing that bit.
Let's say you have one language that supports double-quoted strings and interpolates local variables, like this:
x = 17
print "The number is $x"
produces:
The number is 17
Let's say in some situation you don't want interpolation, and so you want to mix in some other language that supports interpolation-less strings, and it just happens to use triple-quoted strings as the syntax for that behaviour. So, we make a new language by combining the original language's expression syntax with the new language's expressions syntax using the ordered choice operator. Then we feed it this input:
x = 17
print """The number is $x"""
This time, the first language's parser sees the opening quote, then immediately afterward it sees a closing quote. Then it sees another opening quote, some text, an interpolation and a closing quote, then lastly another opening and closing quote, so it yields three string literals and concatenates them to produce one large, interpolated string.
Even though our combined grammar had a special rule for triple-quoted strings, we couldn't use it just by blindly concatenating parts of the grammar; we'd have to rewrite both of them a little bit to get them to mesh nicely. Granted, the above is a slightly contrived example, but most non-trivial PEG grammars have to pay at least some attention to the order of their ordered choice operands, even within a single language.
I still don't understand what's the problem here. User must be aware of the order of a choice and insert his language extension accordingly. Paying some attention to what you're doing never hurts anyway, and it's hardly a blocking issue barring PEG adoption.
I normally do this sort of things by providing a number of extension points in the grammar, in the beginning, middle and the end of a semantic entity, instead of simply concatenating grammars (e.g., see such extension points here: https://github.com/combinatorylogic/clike/blob/master/clike/... )
[0] http://www.cs.cmu.edu/~aldrich/wyvern/