[pro] Lisp 2's and function values.

Marco Antoniotti antoniotti.marco at disco.unimib.it
Sat Jun 4 10:34:50 UTC 2011


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.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20110604/26331757/attachment.html>


More information about the pro mailing list