You're now taking a list of lists and trying to add a number to each list. That should fail - partial evaluation or no. There's no sane way for the first expression to translate in to the second.
As chrisdone pointed out, your first two examples actually add complexity. The last one doesn't make sense. You've written a function that takes and argument and subtracts four from it. One would expect this function to return an integer, not a function.
Arc is intended to not be attached to any other language or VM. That's not to say you couldn't implement your own Arc runtime on top of a language of your choice. In fact, since there are already Schemes that run on top of both C and Java, you could do so simply by porting the Scheme parts to an appropriate Scheme. It's under 1000 lines of Scheme.
Is this a troll or a serious question? The short answer is that they're not intended for the same purpose, and newLISP has several characteristics that most Lisp users consider to be mistakes.
I'm willing to bet that many Lisp users will find characteristics of Arc to be mistakes too. Unhygienic macros is the obvious one from the Schemers prospective.
Driving a Ferrari is rarely a collaborative endeavor :-)
Keeping `_' safe in fact increases the programmer's freedom. If I knew that by doing something I was going to fk up w/ other people's code and how they expect their code to behave, I would rather not* do it. OTOH, if there are namespaces, etc. then I know that I can enforce whatever coding conventions I want, in the privacy of my personal sandbox.
Programming is not only about communicating w/ computers; it is also about communicating w/ other people, i.e. your coworkers and so on. Nothing that makes it harder can be a Good Thing. (Of course, unless you are the Lone Wolf coding in your cave---but then you are probably using your Own Better Language and don't care about Arc anyway ;-).)
Freedom is an interesting philosophical topic. How can a restriction make you more free? Well if you drink the FSF GPL Richard Stallman branded Kool Aid, you might "get it", but I sure don't.
I don't want the freedom from doing things, I want to the freedom to do things.
That said, strictness and protection and safety of some language features is something some people would like to rely on.
I think operator overloading in C++ was a huge freaking mistake for instance. You can look at two piece of code without going through some contextual learning to find out what the hell "+" was just redefined to do, and I think that's crappy.
Other languages get by some how without operator overloading. And often without a loss of expressiveness.
That said, judicious use, and education about how subsystems in software work is a necessity even in the presence and absence of things people might consider to be abominations, like operator overloading :-)
Imagine a Ruby library redefining what + does for numbers. Globally redefining the syntax of the language is almost certainly a mistake unless you're developing a new language. Of course, you might want to design a new language by redefining the built-in functions and macros of Arc.
Redefining _ introduces horrible bugs? Don't do that then.
