"if I understand your system correctly, you can still wrap everything in parens, just like in Arc."
Yes, that's the hypothesis of paren-insertion. So far I've seen two troubling cases, where you have to worry about paren-insertion even if you are explicitly adding parens everywhere:
a) A long data list that wraps to multiple lines:
(a b c d ...
e f g h ..)
My solution is to distinguish this from code indentation by using a single space.
(a b c d ...
e f g h ...)
Most of the time you can use any number of spaces to indicate indent, just like in python. But I'm hoping nobody wants an indent of 1.
b) The second case is arc's multi-branch if statements:
(if
cond1 then1
cond2 then2
else)
or pg+rtm's approach:
(if cond1
then1
cond2
then2
else)
I'm not sure what to do about that. It's why the body of and has two nested ifs where one would seem to do -- I couldn't figure out how to indent a single if :/
Hmm, now that I see your cases and mine I realize in all these cases you can always back off to inserting parens everywhere, and things will just work. Lines where the first token is a '(' never insert a fresh '(' before.
[1] Sorry I edited grandparent to add the pg+rtm case you were adding at the same time in your response.
"Hmm, now that I see your cases and mine I realize in all these cases you can always back off to inserting parens everywhere, and things will just work. Lines where the first token is a '(' never insert a fresh '(' before."
Right. At least, that's how I would expect it to behave. Worst-case scenario, you just put in parens just like Arc. But even then, you can at least leave off the initial parens:
if (foo)
(bar)
(qux)
There is one thing that concerns me, though... it's very common to want to return a value from an "if", like so:
if (condition? x)
+ x 10
x
Whoops, the last "x" is wrapped in parens... but you don't want to call x, you want to return it directly. So you have to wrap the "if" in parens:
A single word on a line is never wrapped in parens, though it may close parens inserted in a previous line.
I keep thinking there's an example similar to this one of yours that won't parse correctly unless you explicitly wrap the if in parens:
if (foo)
(bar)
(qux)
But I can't think of a counter-example :)
Even if the algo is unambiguous this approach will fail if people can't easily wrap their heads around what it will do. But that's a matter of taste, I suppose.
