4 ms·

Thanks a lot for the comments. You seem to know much more about these things than I do, so I don't have much to add. 2. call-it: What's the problem with not kn

by ced 19y ago

Thanks a lot for the comments. You seem to know much more about these things than I do, so I don't have much to add. 2. call-it: What's the problem with not knowing (+ 1 2) until run-time? Efficiency? Then I would argue that expressive power of the core language ought to take precedence. In an actual implementation, funcall could leave (+ 1 2) to be evaluated (or not) inside the function body. I would add funcall-normal-function to the language, which would amount to a funcall + (declare (normal-function f)). Both for documentation and for efficiency. Of course, not knowing if (funcall x (print 2)) will print 2 is unsettling in a way, but that's the same basic argument that's made against macros. They disrupt the evaluation order. I read about normal-order before, but it didn't make much practical sense. I'll Google your pointers and look it up.

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.

by ced 19y ago

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.