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