Hm, you seem to use the . notation as Python uses decorators, but chaining multiple decorators has a very different effect. In python, I'd expect foo.bar.3 to be (foo (bar (3))). In Arc, it seems to do (foo bar 3).
Precisely! Now, just make emacs replace "no" and "not" functions also, and you'll have what I was asking for.
However, my point is also that doing this kind of thing should be within the scope of PG's work - providing a "reference IDE" to show how he intends Arc code to be interacted with.
andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before. http://plpatterns.com/post/37655849/1-2-n
Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.
Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features. http://mindprod.com/project/scid.html
I thought that the Arc source for Hacker News and the Arc Forum was available somewhere. Unfortunately, I cannot seem to find it. Can someone please post the URL?
Like languages, IDE design and syntax highlighting are sometimes considered "a matter of taste an opinion". But if we disregard this common wisdom, what is a good (the best?) way to highlight s-exp's, variable scope, etc?
It's only a problem if fns of two or more args are common, and they don't seem to be. In news.arc, srv.arc and blog.arc they appear once every 123 lines. In my CL code they appear every 250 lines. Are they more common in your code?
almost all Arc functions take either one, two or three arguments, with the last one often being a rest argument. So these are the cases that need to be optimized
Although the other analysis is insightful, IMO, this is the most important part of your post. Although, I'm not looking to optimize all functions, just those with bodies smaller than about twice the size of the "fn (argument list)" code.
The only things I don't like about arrow form are 1) two characters, and 2) it looks like other math symbols.
I like the colon form, but some text editors make it almost invisible. If the font makes it bold enough, it can be easier to recognize than many of the others.
I originally like the pipe form, as it's also pretty obvious. However, since this is a lisp, you can always rewrite it to suite your individual tastes ;) How about writing a "config" file for arc, and various conversion tools, that allow us to all write in our own style, and easily convert between them? Then we wouldn't have to argue over which separator to use.
I implemented something like the first one in my m-expression reader, "a -> b;" is translated into "(fn a b)". It could be used with cchooper's customisable reader, so you can still use s-exprs most of the time, like this:
