"(I hope to also lose the parens around the recursive call to and.)"
You mean remove the parens inside quasiquote? Good luck with that.
---
"But hey, it's up to the programmer to use tools tastefully, and to figure out what good taste is."
Exactly. I'd rather have implicit parentheses, because then I can choose whether to include parens or not... if I understand your system correctly, you can still wrap everything in parens, just like in Arc. So it's up to the programmer to decide whether to use parens or not. I think that's a very good thing.
"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.
Ah, right, I thought you meant getting rid of `( ... ) Yeah, that seems okay. But in that case, you'll probably never be able to completely fix the issue where you have a long list of data, as described in the other post.
You could probably come up with a compromise that works the majority of the time, though. For instance, you could disable indentation inside of '( ... ) but still allow for indentation with `( ... )
Yeah that's a good point. If this approach is too aggressive I can back off and disable paren-insertion inside parens. I already do that to make things like this work:
Yeah if I could get rid of that one we'd be able to add macros to C or python :) But imagine a language that can look like python most of the time. But if you want macros, then the parens return.
