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
