
Eco: A Language Composition Editor - tomaskazemekas
http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language_composition_editor/
======
epenn
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.

[0]
[http://www.cs.cmu.edu/~aldrich/wyvern/](http://www.cs.cmu.edu/~aldrich/wyvern/)

------
scotty79
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.

------
michaelmior
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.

~~~
kot-behemoth
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!

~~~
michaelmior
Good point :)

------
sklogic
I do not understand how the PEGs ordered choice is a problem. Never had any
issues with it.

~~~
thristian
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.

~~~
sklogic
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/...](https://github.com/combinatorylogic/clike/blob/master/clike/clike-
parser.hl) )

