Email list hosting service & mailing list manager

Comment on SRFI-110 and Comparison to Genyris xyzzy Bill Birch (22 May 2013 15:03 UTC)
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy David A. Wheeler (23 May 2013 13:39 UTC)
sweet-expressions are not homoiconic John David Stone (23 May 2013 16:08 UTC)
Re: sweet-expressions are not homoiconic John Cowan (23 May 2013 16:19 UTC)
Re: sweet-expressions are not homoiconic John David Stone (23 May 2013 16:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:12 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 15:34 UTC)
Re: sweet-expressions are not homoiconic John Cowan (24 May 2013 20:02 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 20:09 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 21:35 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 22:40 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 23:13 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 03:43 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 03:20 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:17 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 04:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 18:14 UTC)
Re: sweet-expressions are not homoiconic John David Stone (26 May 2013 23:26 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:29 UTC)
Re: sweet-expressions are not homoiconic John David Stone (27 May 2013 15:51 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (28 May 2013 04:28 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (28 May 2013 18:34 UTC)
Re: sweet-expressions are not homoiconic Beni Cherniavsky-Paskin (26 May 2013 20:40 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (26 May 2013 22:43 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:00 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 03:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 04:44 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 05:50 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (27 May 2013 06:34 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 15:14 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:55 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 16:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:55 UTC)
RE: sweet-expressions are not homoiconic Jos Koot (27 May 2013 04:57 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:37 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:50 UTC)

Re: sweet-expressions are not homoiconic David A. Wheeler 27 May 2013 13:55 UTC

Alexey Radul <xxxxxx@mit.edu> 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