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.
