On 25 May 2011, at 21:40, Marco Antoniotti wrote: > Hi > > I don't think there is a reasonable objection to forbid a form like > > ((returns-something-funcallable arg1 arg2 ... argN) 1 2 3 ... N) > > from "working as expected". As Martin pointed out, if the return value of > the form is a "macro" then this would have to be interpreted in the "regular" > evaluation regime.
The main issue I have with this is that at the moment, you have only explicit shifting operators (funcall/apply and function/symbol-function/fdefinition). A proposal like the one above would introduce implicit shifting. You already have implicit shifting in the sense that placing a symbol in the car or any of the cdr positions is already enough to fetch something from the function or the value namespace. However, you can only do this with explicit function/variable names directly in the "user" code, or by constructing the correct s-expressions in macro definitions. With a proposal like the above, you would add another level of implicit shifting. If I define a function, say (defun foo () 'bar), and a corresponding macro (defmacro foom () (foo)), then without explicit shifting and without macros, I can only use this to generate a variable name (baz (foom)), but not to generate a function name, because ((foom) baz) fails. With the proposal above, ((foom) baz) wouldn't fail. I prefer the explicitness of (funcall (foom) baz), especially because if you really, really, really want it implicit, you can still have it your way anyway. Pascal -- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
_______________________________________________ pro mailing list pro@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro
