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.
