Arc Forumnew | comments | leaders | submitlogin
Notation for s-expressions using indentation
2 points by blatta 6115 days ago | 8 comments
My proposal aims not to break traditional notation. An s-expression consisting only of parens, atoms and whitespace should read normally.

Instead, if a special token appears at column N, it "opens" an s-expression (just like a left paren), which is closed when the next line starts in a column <= N.

E.g. if the token were ":", then

  (def rev (xs) 
    ((afn (xs acc)
       (if (no xs)
           acc
           (self (cdr xs) (cons (car xs) acc))))
     xs nil))

could be writen as

  :def rev (xs) 
    ::afn (xs acc)
       :if (no xs)
           acc
           (self (cdr xs) (cons (car xs) acc))
     xs nil
or even:

  :def rev :xs
    ::afn :xs acc
       :if :no xs
           acc
           :self (cdr xs) :cons (car xs) acc
     xs nil


2 points by cadaver 6115 days ago | link

Writing out the following from scratch:

    (def func ()
      (if cond
          true
          false))
  -><- editor's suggested level of indentation
is about as much work as writing:

    :def func ()
      :if cond
          true
          false
  -><- forceful break of suggested indentation through backspace
So, I suppose, that's not an issue. What is an issue is that, if you revisit your code and want to add/remove something, you'll either need to use smart editor commands that let you navigate and edit your code based on s-expressions rather than rows/columns, or you'll have to sort out closing parens by hand.

If you have indentation based syntax, the sorting out by hand is replaced by matching the indentation level to the s-expression you want to modify; much easier, especially if you have programmed in non-lisp languages and are new to lisp, like me.

Here, for what it's worth, comes my insight: practically the same functionality that is gained by your proposed system could be gained by making the editor interpret a forceful break of indentation as a command to add/remove closing parenthesis of the last s-expression, e.g.:

    (if cond
      (do (one)
          (two)))
  -><- ;we start here and want to add another expression to (do ...
    -><-) ;we break the editor's suggested indentation once and the editor
          ;places if's ')' after the cursor
        -><-)) ;we break indentation twice and the editor
               ;places do's ')' after the cursor
          (three)-><-))
This is just one case of course. The editor also has to manage closing parenthesis when you break suggested indentation in the middle of an s-expression, and there are likely to be other things I've not thought of, but essentially, the editor can unambiguously manage parenthesis for you by responding to user-override of the current indentation level.

I almost feel up to try to implement this in emacs lisp. But maybe I should just try and learn, I don't know, quack-mode (which I'm using right now) or SLIME-mode of which I've only just heard through this forum.

-----

2 points by kennytilton 6114 days ago | link

"you'll either need to use smart editor commands that let you navigate and edit your code based on s-expressions rather than rows/columns, or you'll have to sort out closing parens by hand."

The beauty of parentheses is precisely being able to edit code in meaningful chunks because the parentheses naturally organize our code that way, which is part of why I think Arc's philosophy of "First, we kill all the parentheses" is away from goodness.

When I do edit code as if it were just so many lines and characters (about half the time -- after a dozen years I still have not mastered more than a few keychords) a simple "reformat" keychord automatically puts everything where it should be. And I am rarely disappointed by mistakes because the editor is still giving me cues by auto-indenting when I hit TAB and by blinking matching parens as I type.

I would suggest folks spend a few weeks writing Lisp before they try to change it, they might be surprised how they end up feeling about the parens. Unfortunately pg himself has it in for parens, so I cannot blame you all for the syntax massacre I am witnessing. :) A non-problem is being solved.

-----

1 point by eds 6114 days ago | link

I took a shot at writing an indentation based syntax a while ago. You don't technically need the colons, although that makes it difficult to introduce new parens mid-line.

http://arclanguage.org/item?id=1917

I like the idea of indentation based syntax, but the colon solution looks like only half a solution. You only remove half the delimiting characters, and the ones you remove are the ones that are the easiest to type when you have a good editor. (In fact, some editors even add them for you.) Considering that I prefer parens to colons as delimiters, I would currently prefer to stay with s-expressions.

And as much as I might like indentation based expressions, kennytilton has a good point about editing code. In indentation based syntaxes, you have to redo the indentation manually (or rely on an editor to guess), whereas in traditional lisp you can just hit the auto indent key (since indentation can be determined programmatically).

-----

1 point by applepie 6114 days ago | link

The colon proposal attempts to be orthogonal to traditional s-expression notation (every s-expression in traditional notation keeps reading the same as always, no matter how it is formatted).

> I like the idea of indentation based syntax, but the colon solution looks like only half a solution

Well, if we want to read s-exprs, _somehow_ the programmer must hint the reader about where the parens go.

I don't want the reader to guess what I mean, or juggle with whitespaces.

I think the colon notation is more visually appealing than "just parens", and doesn't hurt programmers who don't want to use it.

-----

2 points by cadaver 6114 days ago | link

Since, as I've pointed out, the editor can handle the parens for you completely and unabiguously, even without any special commands, you could simply turn-off, parens that exist in addition to indentation, make them invisible.

If you then additionally make the editor display the opening parenthesis as a colon then, voila, you have the visually pleasing colon syntax.

In such a mode you'd always have to be indentation perfect, but just as with colon syntax, you can simply switch to a more traditional editing mode.

-----

2 points by drcode 6115 days ago | link

to format code in comments, prepend them with an empty line and indent the lines of code at least 2 spaces.

-----

1 point by blatta 6115 days ago | link

Thanks!

-----

1 point by applepie 6115 days ago | link

Even being a long-time lisper (meaning I don't feel parentheses are evil), I found the colons visually more pleasant.

-----