4 ms·
> call-it: What's the problem with not knowing (+ 1 2) until run-time? Not only efficiency. You don't even know if (+ 1 2) means "1 plus 2" or "choose 1 or 2
by shiro 19y ago
> call-it: What's the problem with not knowing (+ 1 2) until run-time?
Not only efficiency. You don't even know if (+ 1 2) means "1 plus 2" or "choose 1 or 2 randomly" or "generate a sequence of numbers between 1 and 2" until you know what x really is (assuming funcall does delay evaluation of its arguments and passes the original form in case x is indeed a macro).
The macro version of call-it has the same problem, of course, but if you embrace first-class macros in the above way, every higher order function call will have the problem. Considering how often HOF is used, the impact is huge.
However, as you suggested, you can have two versions of funcalls, one of which evaluates args no matter what x is; then this problem will be solved.
(Or you can use hygienic macros, then you can deduce what '+' means purely from its lexical context, at least.)
- ced 19y ago> Considering how often HOF is used, the impact is huge. Well, yes, that would be the point :) I think I understand what you mean, but I don't see how this is more dangerous/worrying than what is already there. Ok, so (funcall fn (+ 1 2)) may or may not evaluate (+ 1 2). But call-it is already willing to give total control to fn. Will fn call a continuation and never return? Launch nuclear weapons? Giving it additional control over the evaluation of the arguments seems innocent enough.