<div dir="ltr"><div><div>More of a thought exercise than a discussion of actual features: i recently read about this editor for composed languages, eco:<br><ul><li>site: <a href="http://soft-dev.org/src/eco/">http://soft-dev.org/src/eco/</a></li>
<li>paper: <a href="http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs">http://tratt.net/laurie/blog/entries/an_editor_for_composed_programs</a></li><li>repo: <a href="https://bitbucket.org/softdevteam/eco/">https://bitbucket.org/softdevteam/eco/</a><br>
</li></ul></div></div>Just from their examples, I now have this picture in my mind of a codemirror-based, eco-like editor in a cell that lets me prototype an interactive GUI driven by a couple SPARQL queries with python interpolated inside the querie, without any templating stuff in sight. I can mix in Widgets wherever I like. Hell, throw in some coffeescript and LESS.<br>
<div><br></div>At first glance, it's a 90's PHP nightmare, but then I remember that I can immediately tell if all of the layers are syntactically correct, since each layer was interactively built against a grammar, augmented by what is known about the current running environment.<br>
<div><br>Some things I thought about:<br><div><ul><li>what is a composed kernel(s)?</li><ul><li>they don't really cover how one might actually <i>execute </i>one of these files. for their example with HTML, Python, SQL, what's really happening? in my mind, this is really just a python kernel that wraps HTML and SQL as strings, but a more involved example?</li>
</ul><li>how would parser-driven editing in context work?<br></li><ul><li>the completion available in a running kernel is already far beyond what a  grammar-only completion tool can do. what would a more aggressively parser-driven editing experience be like?<br>
</li></ul><li>how would one store a tree of tokens?<br></li><ul><li>presumably, storing serialized JSON in cells[].source, while ugly, would work. or metadata.<br></li></ul><li>what are <a href="http://soft-dev.org/pubs/html/diekmann_tratt__eco_a_language_composition_editor/#x1-220009.2">visual tokens</a> like?<br>
</li><ul><li>actually, in line with the jupyter iconography (i.e. galileo's moon), the inlining of visual tokens would be incredible. codemirror doesn't appear to support flowed widgets (yet?). their suggested "real" use, of a formula editor, is interesting. And, of course, matrices.<br>
</li></ul><li>eco native format is gzipped JSON</li><ul><li>i think this has been 
discussed before (ipynbz). i don't know what advantage this provides 
over just having the json out there, but i have created some pretty big 
notebooks before. also, notebook files are not really hand editable 
(though I have done so).</li></ul></ul>Interested in what other folks think...<br></div><div><p>Cheers!</p><p>Nick<br></p></div></div></div>