Considering the expression above is trivially small it would be easiest just to leave it as is. (My program doesn't mess around inside lists, it only tries to interpret free symbols at the top level of input.)
But I think I know what you are really getting at, because when the single letter symbols above are more complex expressions, converting the above gets much more difficult. The fact is, in a system where indentation is significant, you can't make arbitrary decisions about indentation to make the code look the way you want. So either you have to line everything up equally so you can't distinguish between test and expression, or you need to come up with some fancy indenting rules that somehow know what an if expression is supposed to look like. I don't particularly like the former, and I'm to lazy to really work on the latter, so that leaves us with just having the badly formatted if expressions. (Unless someone else can think of something. Maybe that discussion does, but I don't entirely have time to look through their archives right now.)
But at the very least I am having fun messing with Arc internals, so not all is lost.
Yeah, I don't know what to do about that one. I've been thinking about it for a while, I just didn't know that was what you were asking.
I can't see any way to make indentation show you need just a symbol and not a function call with no arguments. You could add symbols, but that works against the removal of the parentheses in the first place.
Its a bit of a hack but if you had a simple read macro for an identity function you could do it. (Quote doesn't quite work because it prevents evaluation.) But say you had a function identity like such:
(def identity (x) x)
And you defined a CL style read macro (e.g. $) to expand to (identity x). Then in my current function, because the read macro would expand before checking the subexpression to see if it was a list or not, you could do the following:
Which basically exchanges all the parentheses in the traditional version for a identity macro. Of course, it isn't exactly the same because you are adding extra meaning (the call to identity) to the expression. But maybe you could make it a macro instead of a function, and do the expansion at compile time (although this is dangerous because if you expanded the macro too soon you would defeat the purpose of using it in the first place...):
(mac identity (x) x)
On the other hand you could alway just use traditional s-expressions in the middle of significant-indent code. The goal is to make parentheses optional, not to remove them entirely. Sometimes it may just be more convenient to leave them in than take them out.
I just thought of another solution which might fix this problem without needing any special syntax characters.
If you consider that the reason we know to add parentheses around structures in the first place is the indentation of forms below the current line, then it is ambiguous whether a form with no nested forms should be wrapped in parentheses or not. If the system then does not assume the innermost forms are function calls, then it solves the problem of interpreting literals as function calls. Thus you can now do this:
if
test
exp
exp2
(very-long-exp3 5 6 7 8)
(some-random-exp4)
test2
exp5
(exp6)
(exp7)
Which cleans up many parentheses (removing all parentheses was never our goal in the first place), and doesn't result in the extra parentheses that were a problem before.
Note that the above syntax is already what is pretty much the basis for all i-exprs in the mailinglist I posted, which is the main reason I posted the mailinglist.
