Eco: A Language Composition Editor

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.

A typical language mixing example is literate programming: you have your programming language embedded into a markup language (say, latex).

Another example is embedded assembly, embedded regular expressions, etc.

I also find it quite useful to be able to use embedded Prolog, to embed BNF parsers, etc.

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.

[1] http://aspen.io/simplates/ [2] https://bitbucket.org/softdevteam/eco

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.

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.

[1] http://gbracha.blogspot.com/2014/09/a-domain-of-shadows.html

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.