Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pretty Lisp

pretty-lisp.org

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Pretty Lisp

#61

Post by doty »

timmy-turner wrote: post #52
ken wrote: post #34

Earlier quoted context omitted.

I've given this a lot of thought, because I'm working on a couple of vaguely similar projects. My conclusion so far is that pretty-printing is great, but enforcing structural constraints in the editor (beyond perhaps something like ParEdit) tends to cause more trouble than it's worth. Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are t…

> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this. I hope that this can be mitigated by using an incremental parser (pretty easy…

I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions.

It turns out to be fantastically empowering.

Re: Pretty Lisp

#62

Post by calibraxis »

sedachv wrote: post #56
calibraxis wrote: post #42

Earlier quoted context omitted.

Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). ( https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2... ) Paredit, a favorite among modern Li…

Paredit is nice, but barely works for stock Lisp syntax. One of the best things about Common Lisp is reader macros, and in order to integrate them with structured editing, you'd need to change the reader macro mechanism to be based around a composable context-free grammar description that can be shared between the reader and the structure editor. I'm pretty sure that's still an open research problem. Personally I thi…

At least among the Emacs-using Common Lisp users I've known (and discussed the topic with), Paredit is considered a clear win. Same in my experience. What do you use? If there's something better, I'd be happy to use it.

(When I last observed someone editing Common Lisp code without turning on Paredit, it was rather depressing, how much time he spent closing parens and re-indenting everything. But maybe you use something else which avoids this problem?)

Reader macros (in the worst-case scenario you describe) are a very rare use-case, and therefore probably not worth optimizing an IDE for. Perhaps for you they're common, but I'm virtually certain that most Common Lisp users have never written even one. If macros are already uncommon to write, reader macros have a far higher bar of justification.

Re: Pretty Lisp

#63

Post by spitfire »

doty wrote: post #61
timmy-turner wrote: post #52

Earlier quoted context omitted.

> Consider the transformations you might do on a piece of source code while you're playing around. A lot of these (for me, anyway) are things which change not just position or name, but the part-of-speech of words, or temporarily make a nonsensical expression. (I do it in my shell a lot, too.) Rigid structure-enforcing editors hinder this. I hope that this can be mitigated by using an incremental parser (pretty easy…

I worked on a language once (now dead) which even had a syntactically valid form for parse errors, which allowed a structured editor to record a valid AST at all times. The "parse error" expression just raised a "parse error" exception at runtime, so you could even execute ill-formed expressions. It turns out to be fantastically empowering.

Which language?

Re: Pretty Lisp

#64

Post by calibraxis »

pavelludiq wrote: post #57
calibraxis wrote: post #42

Earlier quoted context omitted.

Sounds unlikely. May I ask what experience you had with 1980's structure editors (presumably Interlisp)? My reading of history is that it wasn't rejected by users, but rather killed off by MacLisp implementors teaming up to create Common Lisp, thereby getting the ARPA funding (when ARPA wanted to consolidate Lisp). ( https://groups.google.com/forum/#!msg/comp.lang.lisp/Llmnxk2... ) Paredit, a favorite among modern Li…

I'm a lisp history nut, but I wasn't around at that time. Paredid doesn't really turn emacs into a structure editor, its more like a "standard editor with some of the better ideas of structure editors miked in" kind of mode. Structure editors introduce a lot of complexity in general. Maybe Interlisp was able to work well in practice despite the added complexity, I don't know, I really would like to know more about su…

You might be interested in the debates between Stallman and Sandewall. It's in _Interactive Programming Environments_; Stallman took the side of text editing, and Sandewall took the side of structure editing. The book is maybe a good gift for Lisp history nuts, and it's only $3 used on amazon.com.

Re: Pretty Lisp

#65

Post by spitfire »

taliesinb wrote: post #59
spitfire wrote: post #55

Earlier quoted context omitted.

Are you talking wolfram workbench or eclipse? (I don't have workbench). If eclipse has mms support I'll be trying that out tonight.

Ah, my bad. You can install it as an Eclipse plugin, but that seems to require access to an internal server. So guess you're stuck with the Workbench, our branded version of Eclipse, which requires "premier service". Sorry!

Yeah. I don't have premier service. (When it says "call for quote" I leave) I'm guessing you work for wolfram?

Is there a demo available somewhere?

Re: Pretty Lisp

#66

Post by pshc »

pavelludiq wrote: post #18
pshc wrote: post #9

Looking sweet. The future is in structural editors. The client-server separation is a nice bonus. Unfortunately this is running up against the UI problem. How do you make this intuitive and powerful? A lot of hard work on usability is needed to get up to par with text editors. Very glad to see it being tackled.

In the lisp universe the future was in the 80's, thats when we tried the whole "structural editors" idea and concluded that they didn't work out as nicely as we hoped. I believe the sgml people tried them too, with poor results as well.

It is a huge UI problem. For example, it's tempting to start adding flashy chrome to a structure editor just because you can. Pretty Lisp's rounded rectangles are obviously not going to scale to real programs; they generate a lot of noise. Visually, an ideal structure editor looks a lot like the text-format code we have today for its readability.

There's a lot of usability failure in Lisp's history but I know that a great structure editor is possible.

Re: Pretty Lisp

#67

Post by jimbokun »

spitfire wrote: post #2

I've been wanting this sort of thing for ages. Considering how sophisticated we think we are, how the hell are we still using tools like emacs, or even VS on a daily basis? We should be indistinguishable from magic by now. This is a (small) step in the right direction. Can we please live in the future already?

When you want to write an essay, do you use something that draws your essay as some complex graphical representation, or do you use something like Word or a text editor, that for the most part shows your essay as just a bunch of boring characters on the screen?

Sure, there may be some fonts and indentation and colors. (Eclipse and VS use those, too.) But the text is the point.

It's the same with code. Code is a means of expression, best treated as text. Every attempt at turning it into something graphical always reduces the expressiveness.

Re: Pretty Lisp

#68

Post by strags »

What you gain in "readability" here (debatable), you lose in terms of screen real-estate efficiency. The last screenshot has a function filling the entire screen that would, under ordinary circumstances, occupy about ten lines of code.

You're going to get frustrated having to page up and down continually in order to understand any remotely complex function.

Re: Pretty Lisp

#69

Post by madhadron »

The boxes seem to be an unstable medium between the stable points of S-expressions and indentation as nesting. If there are lots of nested expressions, you either push them to multiple lines and it becomes indentation, or you keep them on one line and the top and bottom boundaries of the boxes run together until you effectively have parentheses.

Have you looked at Chuck Moore's ColorForth, though? It might be a neat direction to take this in.

Re: Pretty Lisp

#70

Post by gringomorcego »

taliesinb wrote: post #60
lambda wrote: post #58

Huh. I wouldn't call this pretty. Why do you need a box around everything? One of the arguments about Lisp is how visually distracting the parentheses are (and yes, experience Lisp hackers learn to tune them out; that doesn't change the fact that they are visually distracting); the boxes are even more visually distracting. To use Tufte's terminology, this is decreasing the data-ink ratio, not increasing it. Take a lo…

I elaborate a bit on this point in my comment below about Scratch. My claim is that this 'pretty lisp' is still stuck in the flat-text mindset, doing something pretty much identical to indenting. Whereas what we really want are graphical (in the sense of network) editors.

Can you elaborate?
Post reply on HN