[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sweet-expressions are not homoiconic

This page is part of the web mail archives of SRFI 110 from before July 7th, 2015. The new archives for SRFI 110 contain all messages, not just those from before July 7th, 2015.

Alexey Radul <axch@xxxxxxx> wrote:
> Then I strongly recommend you try [Paredit]...

Okay, I'll give Paredit a whirl.

>  ... May I suggest writing an Emacs mode for
> sweet-expressions as a fitting project for learning Paredit?

I'm hoping someone else will pick up the "write an emacs mode" part;
I don't have unlimited time, and I expect serious emacs mode
creation to take time.  But I can certainly sit down
and try fiddling with Paredit.


> Oh, certainly there are editing modes for Python and C++...
> [In ParEdit]...  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.

Somehow I hear Morpheus saying this :-).

Hopefully this mode won't launch me into a dystopian world where I have
to eat snot for breakfast :-).

> 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.

That sounds very nice.  But that, at least, would be trivial to implement
in any sweet-expression edit mode.

> > 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,

Agreed, but you then have to move the cursor to what you're looking at.
My eyes can move faster than my hands.

> though this has precious little to do with the syntax.

Fair enough.

> 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.

In sweet-expressions the indentation should be clear to start with, since
it's actually *used*.

>  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.

Well, I can certainly try it.  And maybe someone else can propose something.

> 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."

Oh, I think so too.  I just don't think it's *enough*.

--- David A. Wheeler