I'm not worried about its lack of 'eval so much. They're placing a strong emphasis on ClojureScript's ability to leverage the Closure Compiler to weed out dead code. Inasmuch as they encourage dynamic programming techniques at all, they'll end up with dynamically minded libraries that make their compile-time efforts seem weaker than they are. Apparently they draw the line at reflection, and 'eval is beyond that point.
What I'm more worried about is that under the current plan, it looks like there "won't [ever] be" any "thread-related things" (http://cloud.github.com/downloads/clojure/clojurescript/cloj...). I don't find Clojure remarkable for static analysis, for syntax, or for collaboration between programmers. What I find remarkable about Clojure is the way it furnishes its standard libraries with things that anticipate concurrency, so that when people write their own concurrency-related Clojure libraries, they're all likely to synergize with each other.[1] Even if ClojureScript doesn't get to have shared-state concurrency thanks to the JavaScript platform,[2] I think it would be great if its biases could somehow be repurposed for use with web workers or AJAX.
[1] At least I imagine they synergize. I haven't used Clojure or stumbled upon many concurrency-related Clojure libraries, so I hardly know how well they work together in practice.
In practice, in both my Arc and JS code, I use eval only when I absolutely have to... which is almost never. It's usually when I'm doing something incredibly hacky, like trying to eval macros at runtime...
Anyways, the traditional wisdom in JS is to avoid eval as much as possible. 99.99% of the time, eval is bad. It slows down your code, makes things like static analysis harder (or impossible), and it's usually completely unnecessary.
So, I don't see any practical problems with removing eval, but I do see some philosophical problems. eval has been a part of Lisp for so long, that it almost feels like a Lisp without eval isn't really a Lisp...
In any case, from a practical perspective, a lack of eval isn't a big deal at all. But I can see why some people might want eval (for non-practical reasons).
Having both macros and eval always seemed redundant to me, because they're both for letting you treat code as data. Also, since the eval in most lisps (Arc included) doesn't accept a second parameter for the environment context, they might as well not have eval in the first place.
1. A good theoretical lisp should be fexpr-based and have an eval which accepts both parameters.
2. A good practical lisp wants to be fast, so it should use macros instead of fexprs. Eval is basically irrelevant here.
"...they might as well not have eval in the first place."
Although I agree with you in principle, eval is needed in at least one place: load. So I don't think we can necessarily get rid of it completely, unless we used a different method of loading/evaling files...
eval is also used in a few other places in ar, but not very many. So rather than getting rid of it, I think a better solution is to say, "eval is generally a bad idea, so use something else unless you absolutely positively must use eval" which is exactly what we do.
By the way, I'll note that when I tried to use eval to expand a macro at runtime, it ended up being horrendously slow. I changed it to use a function (which did the same thing, but with thunks) and suddenly my code ran at least 100 times faster than it did with eval.
Ah, you're right. You may not be able to do away with eval.
And do you know what you just helped me realize? If we've already identified ourselves as a practical lisp, why should we try to get rid of features like eval in the first place?
A theoretical lisp tries to get rid of unnecessary features to approach being as minimal as possible. A practical lisp has already decided that it would rather be useful than theoretically minimal.
So a practical lisp probably shouldn't worry about getting rid of things unless they are actively causing problems. If it wants to be as useful as possible, it might as well leave in unnecessary features. Because they're probably still useful some of the time to some people, even if they're not totally necessary.
