An editor for composed programs

Re:An editor for composed programs by tikhonj on Wednesday August 20, 2014 @09:22PM (#8205519)

Emacs's structured editing, in the style of paredit[1], sounds very similar to a text-based version of syntax-directed editing (SDE). Designed for Lisp and S-expressions, it's a system that lets you edit and navigate around nested expressions at a syntactic rather than textual language. As you type, the correct level of nesting is maintained and there are commands for moving and editing code in terms of s-expressions rather than characters.

In practice, it's very easy to start using and very powerful... but requires using Lisp. It'll seem odd if you're not regularly a Lisp user.

Happily, this idea can generalize well enough to distinctly non-Lisp languages. Structured Haskell mode[2] does this for Haskell, which has a less regular and sparser syntax than s-expressions. The documentation has a bunch of handy animations showing the various features, giving you an idea of how it works without having to install it yourself.

This doesn't address the meat of the blog post—composing languages and grammars by taking advantage of structured editing—but it shows that the necessary foundation is possible with a perfectly normal text editor. It would be interesting to see if some of the ideas from Eco could be added to structured editing modes like this without requiring you to use an external, self-contained editor.

[1]: http://www.emacswiki.org/emacs/ParEdit

[2]: https://github.com/chrisdone/structured-haskell-mode

Also, here's a great video of Paredit in action:

https://www.youtube.com/watch?v=D6h5dFyyUX0

[ Parent | on HN ]

Re:An editor for composed programs by klibertp on Thursday August 21, 2014 @05:01AM (#8206499)

> with a perfectly normal text editor

That's... a bit unfair characterization of Emacs. It is built for extensibility, built as a development platform for Elisp packages - and that's not how most editors are designed and coded.

Anyway, it's probably completely possible to adopt many or most proposed features into Emacs but it could be prohibitively hard to adopt them into some other editors.

[ Parent | on HN ]

Re:An editor for composed programs by dgellow on Thursday August 21, 2014 @02:24AM (#8206121)

There is the web-mode for emacs [1] to manipulate files with different languages. It is oriented for editing templates but something more general should be possible.

Currently I am using it a lot to write React's JSX which combine javascript and XML.

[1] http://web-mode.org/

[ Parent | on HN ]

Re:An editor for composed programs by kazinator on Wednesday August 20, 2014 @09:44PM (#8205592)

... and of course, in Lisp you can embed other languages in terms of their syntax trees, so the composed language problem goes away. Your HTML just looks like (html (head ...) (body (h1 ...))) or whatever; no "language box for HTML" needed.

[ Parent | on HN ]

Re:An editor for composed programs by mtdewcmu on Wednesday August 20, 2014 @11:38PM (#8205827)

>> Your HTML just looks like (html (head ...) (body (h1 ...))) or whatever; no "language box for HTML" needed.

In your example, the language composition is smooth because there's only one language there: Lisp. HTML has capitulated.

[ Parent | on HN ]

Re:An editor for composed programs by willismichael on Thursday August 21, 2014 @10:47AM (#8207588)

That's the point, HTML is just a hobbled lisp with an awkward syntax. If you're building a template engine in a lisp, it's much nicer to just use the native lisp syntax instead.

[ Parent | on HN ]

Re:An editor for composed programs by judk on Thursday August 21, 2014 @12:14PM (#8208084)

HTML is a subset of lisp with a different syntax. The rest of your point holds without lashing out at HTML.

In different environments, different syntaxes show strength. What happens if you misplace a ) vs misplacing an </tag> ?

[ Parent | on HN ]

Re:An editor for composed programs by kazinator on Thursday August 21, 2014 @01:49PM (#8208626)

What happens when you misplace a tag, and it's around 1995, is that browsers somehow parse it anyway without complaining, rendering the page anyway. Users then believe that this is the correct syntax: closing tags is optional, as is the order in which it is done. Twenty years later, you end up with a mess of a situation where every browser has to support not only its own historic buggy behaviors but those of other browsers.

You cannot "misplace" a closing parenthesis, at best you can have too many of them not enough. Of course, you can enclose the wrong amount of material, but to see what is being enclosed, you just need parenthesis matching support in the editor. This is more common than XML tag matching support. E.g.

http://stackoverflow.com/questions/500989/jump-to-matching-x...

[ Parent | on HN ]