On Mon, May 27, 2013 at 12:44 AM, David A. Wheeler
<xxxxxx@dwheeler.com> wrote:
> Alexey Radul <xxxxxx@mit.edu> wrote:
>
>> I don't know whether anyone else on this list uses Emacs' Paredit mode
>> http://www.emacswiki.org/emacs/ParEdit to edit their S-expressions,
>
> I haven't used Paredit mode, sorry.

Then I strongly recommend you try it.  I think anyone who takes syntax
design seriously, as you clearly do, should be familiar with the
best-in-class editing tools, lest their design should accidentally
impede their adaptaion.  May I suggest writing an Emacs mode for
sweet-expressions as a fitting project for learning Paredit?

>> ... In any case,
>> I submit that sweet-expressions would become a much more powerful and
>> effective notation if they were to obey the Paredit Property -- or,
>> more broadly, if someone were to implement Paredit mode for them.
>
> Advanced editing modes are definitely desirable!!
> I think there's a reluctance to spend a lot of time creating editing modes
> when the notation itself is still in flux.

My point was that this reluctance, while understandable, is dangerous.
Choices made in the design of the notation have consequences for the
ease of implementation of advanced editing modes.

> ... I certainly hope to see cool modes
> in the future.
>
> I *do* believe that sweet-expressions
> can be well-supported by an editing mode.
> Heck, people manage to support Python (which is indentation-sensitive)
> and C++ (which is notoriously hard to parse) with fancy editing modes.
> Compared to them, sweet-expressions should be a snap :-).

Oh, certainly there are editing modes for Python and C++.  I have had
the good fortune of not needing them, but I have tried the
community-recommended editing modes for Ruby and Haskell, and Paredit
is just a level above.  Heck, I find even Eclipse, with all its fancy
refactorings, to still be slower and less pleasant, on balance, than
Paredit (though maybe that's because I haven't written anything except
Java in Eclipse).  You're editing the syntax tree, not the text file.
I cannot tell you what editing with Paredit is; you have to experience
it for yourself.

>> P.P.S. I was motivated to write this note in part because of the
>> recurrent complaint about 10 closing parens being hard to distinguish
>> from 12.  In the presence of Paredit mode this is simply a
>> non-problem.  Paredit maintains the invariant that one's s-expressions
>> are always well-formed (e.g., typing '(' inserts "()"; typing ')'
>> inserts nothing but moves the next ")" to the cursor and steps over
>> it; etc).
>
> That *invariant* I completely buy in to.
> I have a long-standing habit of always typing the closing paren if
> I'm using an editor that won't do it for me.

What I can't stand are tools that add the closing paren when I type an
open paren, but then add another closing paren when I type a closing
paren, producing unopened items.  I had neglected to mention another
of Paredit's design goals: it doesn't force you to change how you
type.  If you just type as if Paredit is off, Paredit will do the
right thing.

> An editor can help you when you're *typing*, but it's far less helpful when *reading*
> the code.

I'm actually not sure I agree with that.  Navigating to the definition
of an item one is looking at is extremely helpful when reading code,
though this has precious little to do with the syntax.  However, I
find that show-paren-mode solves the paren-matching problem quite
nicely for reading -- just put your cursor on a paren you are curious
about and the matching one lights up.  Which, in an s-expression
syntax, means that I can always see the bounds of any node in the
parse tree.  Together with the s-expression navigation commands (next
sexp, previous sexp, enclosing sexp, etc), this produces a
higher-level reading experience than paper, which is essentially
linear.

In practice, of course, I mainly use the indentation to group what I'm
reading, and rely on show-paren-mode and s-expression navigation
commands as reading aids only when the indentation is not sufficiently
clear.  However, inventing a mechanism not to break these two things
would also be advantageous.  Alas, I do not have a specific suggestion
to offer -- except to advocate Paredit mode to you, as something
valuable that s-expressions have, and that may be worth effort to
keep.

Best,
~Alexey

P.S. I think this kind of read/write tool support may have something
to do with what people mean when they say "the parens just fade away."