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.
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.
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
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
What? They can involve that, but it is very variably. I never do that. I find python, perl, etc are much worse than plpgsql.