On May 26, 2011, at 18:32 , Pascal Costanza wrote:

> 
> 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.

I think this are good reasons, but not enough to disallow the following:

    (<symbol or form-returning-a-function-not-a-symbol or lambda-expression> 
...)

We already have 

     ((lambda (x) (+ x 42)) 0)

Why not have

     ((compose 'first 'rest) '(1 2 3))

This would complicate the call protocol and require more explanation, but I 
really don't see how it would harm the programmer.

Cheers
--
MA









> 
> 
> Pascal
> 
> --
> Pascal Costanza
> The views expressed in this email are my own, and not those of my employer.
> 
> 
> 

--
Marco Antoniotti, Associate Professor                           tel.    +39 - 
02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043               
http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.





_______________________________________________
pro mailing list
pro@common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

Reply via email to