[pro] Lisp 2's and function values.

Thu May 26 09:34:41 UTC 2011

On May 25, 2011, at 23:05 , Alessio Stalla wrote:

> On Wed, May 25, 2011 at 9:40 PM, Marco Antoniotti
> <antoniotti.marco at disco.unimib.it> 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".
> 
> Me neither ;)
> 
>> 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.
>> As per "extending" LET there have been a lot of proposals... IMHO a nice one
>> is to go the LOOP way :)
>> (LETS [var <symbol> <form>]*
>>       [fun (<name> <arglist> <body>)]*
>>       [labels (<name> <arglist> <body>)]*
>>       [values <list> <form>]*
>>   IN
>>   <body>)
>> Of course you can add some ways of extending the syntax by having something
>> like
>> (def-lets-binding <tag> ...)
>> You get the idea....
> 
> It's not about syntax, it's about a missing feature: the ability to
> bind a symbol's function "cell" to a value that's not known at compile
> time. To me, that's a limitation of the spec; given that we have
> funcall, it's obviously easy to implement and would be symmetrical to
> let. With such a feature, the gap between Lisp-1 and Lisp-2 would be
> effectively reduced:
> 
> (let ((list 42))
>  (flet ((list (compose #'nreverse #'list)))
>    (list #'list list)))
> 
> => (42 #<compiled-function (lambda (...) ...)>)
> 
> The code above is horrible, but you get the idea.

Yep.  This has been discussed before (*)...  If I remember correctly you can get almost there by specifying differently what you are doing when dealing with the OP of a form, when this is a symbol. My recollection is that it is doable and that the rationale for not allowing it is mostly to make compiler writing easier (although I think that that should be a piece of cake today).

The problem is that you have to prioritize the namespace you are searching, thus ushering in a more complex set of rules for the programmer to remember.  IMHO, this is not a very good reason to "leave it out" since it has been proved over and over again that languages which increase a programmer's self esteem are also those with the absolutely most convoluted access rules ever :)  Plus these languages are also very successful :)

Cheers
--
Marco

(*) It's in CLL.

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