In the Arc FAQ on paulgraham.com Paul writes, "We may make the index of the cdr be the symbol n, so you could say (x 'n) to get the cdr. Then using the proposed : abbreviation (car x) becomes x:0 and (cdr x) becomes x:n."
Is there still a plan to do something like this? I was recently writing some code in Common Lisp which I ported to Arc which I think shows how this can improve readability. I've posted it to Pastebin to make sure that the indentation comes across:
When programming in lisp you tend to accumulate parens on the right. One way to virtually eliminate this is to have a very low precedence infix operator apply, like Haskell's $. I used : in Atom:
Atom code - `(op: / _ 2)`
Arc code - `[/ _ 2]`
It also opens avenues to python-like block indentation syntax. For example...
Atom code:
def (fact n):
if (= n 0):
1
* n (fact: - n 1)
Arc code:
(def (fact n)
(if (eq n 0)
1
(* n (fact (- n 1)))))
This makes programming in Atom very different from programming in other Lisp dialects, but it's a feature I'd kill for... If Arc had it, I wouldn't have to design Atom. :P
-----------
And then I clarified the meaning of the last example:
-----------
Each line in the indented block is added to the if's line. For example:
Yes, you stumbled right into the problem with this scheme. But it's not really a problem if you accept PG's idea that parens are allowed to be implicit whenever that is the only thing that makes sense.
I have found s-expressions easier to edit with a smart editor than other syntaxes. Having to think again about the layout of syntax doesn't sound very appealing, but I would probably give it a try if someone implemented it.
I wonder if you could try implementing this as another compile step on top of arc (with another REPL layer, etc), and then see whether it becomes more popular to code with or without this.
The most recent plan was to use e.g. x.y!z for (x y 'z).
I almost did this for the current release but left it out because I wasn't sure. I tried rewriting some code using it and it didn't really feel shorter. Whereas : as composition really does make programs shorter.
My current plan for syntax is to use chars in the middle of what would to earlier Lisps have been normal symbols. Restricting the introduction of syntax in this way keeps the Lispy feeling. So foo_bar for example will eventually mean something involving two symbols, foo and bar. But there are only so many characters I can make special in the midddle of symbols, and I don't want to use them up unless I'm sure.
I have been considering using Lisp one day, but I was discouraged by the lack of syntax. So I have created my one homoiconic syntax for my purposes. It has lists, but also tuples and records, and what can be most interesting for you - it has syntactic sugar, which I think can be adapted in Arc or in any other Lisp. If you are interested how I have solved it, have a look at:
http://harpoon.sourceforge.nethttp://harpoon.sourceforge.net/sugar.html
I agree. It removes a lot of redundant characters. There are quite a few errors in the example (unless I'm missing something), but it sure looks a lot better, and the correct syntax would remove just as many (just be formatted a little differently).
Now this'll get me stoned, but what about combining it with a bracket pair that switches on infix? Here's the canonical factorial example in 3 views, implicit brackets on indentation and infix, implicit brackets on indentation, and standard Arc:
The infix looks nicer (to me, but I'm also a non-lisp programmer that understands how lisp works), but probably isn't worth the cost of adding a whole new language element, not to mention precidence rules into the language itself. Representing longer math though it would probably get more and more succinct. I have to say, I'm really taken with the whole implicit brackets thing. The strong Python feel helps with readability (I use Python day to day).
