This principle can be generalized to any function with a "rest", and to any function with optional arguments (provided they are at the end of the argument list).
Yes, currying should be disabled with macros. But they already are.
Macro aren't plain functions. They can't be, with their special evaluation scheme. What is true is that macros and functions from list to lists are isomorphic. So, if I define a macro whose result is an integer, I bet the compiler will kindly notify my blunder when trying to make a list from this integer (right?). Same thing if the macro yields a function. So, any partial application in macro will automatically result in an error, and that particular error should be caught at parse/compile time by any descent Arc compiler.
> So, if I define a macro whose result is an integer, I bet the compiler will kindly notify my blunder when trying to make a list from this integer (right?). Same thing if the macro yields a function.
No, it won't. Because a macro returns an object which is inserted into the code. It's usually a list, but not always. It can be an integer, it can be a function object, and unfortunately the underlying mzscheme doesn't allow tables.
