thoughtupquick
2 HN recommenders · recommended in 3 months, 2019–2021
4:54 · 9K views · Jun 22, 2017
A short demo of SEdit, the structure editor for Interlisp-D on Xerox Lisp machines in the 1980s, which edits code as trees rather than text.
Linked as the clearest view of the legendary structural editor in threads about Lisp environments and structure editing.
3 comments from Hacker News
That's a good suggestion. Walking through a set of interactions is a solid idea. For what it's worth, there are some videos around of people actually doing it with Lisp and Smalltalk systems, and pjmlp already posted a pile of them elsewhere in this thread. I can add a few more: Kalman Reti walking through some interactions with a Symbolics LispM repl: [LINK] Brian Mastenbrook demonstrating Interlisp's SEDIT structure editor in the Xerox Lisp environment: this video Rainer Joswig (lispm here on HN) showing us a little bit of repl and Zmacs interaction on a Symbolics Lisp Machine: [LINK] Rainer again, showing some simple interactions with Macintosh Common Lisp, which was my daily driver for years: [LINK] Ruby programmer Avdi Grimm shows some things that he found cool about Pharo Smalltalk: [LINK] Dan Ingalls (one of the original authors of Smalltalk) in a 2017 demo of Smalltalk 76: [LINK] There are some other things I'd like to find for lists like this, but haven't been able to. In particular, a good demo of Apple's SK8 would be great. If you can imagine a full-color Hypercard that could crack open and reprogram absolutely everything on the screen, including the machine code that drew the window system's widgets, all in a repl while the code was live; in which you could grab an arbitrary widget and drop it on the repl window to get a live variable reference to the widget, and then inspect it, operate on it, and reprogram it, again, while everything continued to run; in which you
I missed the golden age of lisp, but i know this project for its legendary structural editor, SEdit[1], released the year I was born. i found it mentioned in an old paredit readme, something poignant like “paredit is only a shadow of what interlisp was: true structural editing”. [1]: this video
> I-Expressions That's not an EXPLICIT list representation, where the nesting is notated by explicit characters. It's also harder to use in interactive interfaces like REPLs, debuggers, etc., where Lisp lists don't need to have vertical layout. > you do have syntax errors--unbalanced parens. if you use a structure editor for Lisp you don't have unbalanced parentheses. In editors with support for s-expressions, unbalanced parentheses are basically not an issue. > cat hakon.grammar Yeah, Lisp works very differently. It does not use grammars like that. Lisp uses procedures in readtables to read s-expressions. Parsing the code is then done by the evaluator traversing the source or by the compiler traversing the source, with an integrated source code transformation phase (macro expansion). We load a bunch of macros into Lisp and they then are available incrementally. There are syntax-based structure editors (for example they were in Interlisp-D), but they always have limits, since macros can do arbitrary source transformations on s-expressions and those are not based on grammars. this video You are really looking for a very different language experience. Lisp with s-expressions works very different from what you propose. That's why I say: it's not about dropping parentheses, you propose to get rid of some of the core parts of Lisp (how programs are represented, parsed, etc.) and give it a different user interface. That's fine, but it is no longer Lisp like we know it. Other syntaxes