[Ecls-list] ContextL functions with &key args don't work properly in ECL.

Pascal Costanza pc at p-cos.net
Sat Mar 13 13:16:42 UTC 2010


On 25 Feb 2010, at 17:06, Stelian Ionescu wrote:

> On Thu, 2010-02-25 at 15:42 +0100, Pascal Costanza wrote:
>> 
>> On 25 Feb 2010, at 15:32, Juan Jose Garcia-Ripoll wrote:
>> 
>>> On Thu, Feb 25, 2010 at 3:20 PM, Pascal Costanza <pc at p-cos.net>
>>> wrote:
>>>        Hi,
>>> 
>>>        I have changed Closer to MOP for ECL in such a way that
>>>        &allow-other-keys is added when &key is present in a method
>>>        lambda list, so it now does the same ECL does. The change is
>>>        in the Closer to MOP repository. Could you check whether
>>>        that solves your problem? (As far as I can tell, it should.)
>>> 
>>>        I don't think the issue with (debug 3) concerns me as the
>>>        ContextL maintainer, but I'm not user? Do you think that's a
>>>        ContextL issue, or rather an ECL issue?
>>> 
>>> 
>>> I do not know how ContextL expands its method expressions. If they
>>> are unnamed lambda lists, then they will not show with names in the
>>> debugger stack trace, while if they are named lambda lists they show
>>> with proper names. See for instance
>>> 
>>> 
>>> (defvar *b*)
>>> 
>>> 
>>> (defvar *a* #'(lambda (x) (declare (optimize (debug 3))) (cos x)))
>>> 
>>> 
>>> (defvar *b* #'(ext:lambda-block foo (x) (declare (optimize (debug
>>> 3))) (cos x)))
>>> 
>>> 
>>> When compiled and loaded, the following session takes place. Only in
>>> the second case there is a meaningful name in the backtrace
>>> 
>>> 
>>> (declaim (optimize (debug 3)))
>>> 
>>> 
>>> (defvar *b*)
>>> 
>>> 
>>> (defvar *a* #'(lambda (x) (declare (optimize (debug 3))) (cos x)))
>>> 
>>> 
>>> (defvar *b* #'(ext:lambda-block foo (x) (declare (optimize (debug
>>> 3))) (cos x)))
>> 
>> 
>> So in other words I should prefer ext:lambda-block over just lambda?
>> 
>> 
>> Does lambda-block have any other semantics, other than giving a lambda
>> a name?
> 
> A portable implementation of this comes from Alexandria:
> 
> (defmacro named-lambda (name lambda-list &body body)
>  "Expands into a lambda-expression within whose BODY NAME denotes the
> corresponding function."
>  `(labels ((,name ,lambda-list , at body))
>     #',name))

This would be incorrect for the given purpose. Consider:

(defgeneric foo (x))

(defmethod foo ((x string))
  (foo 5))

(defmethod foo ((x integer))
  (print 'a-number))

Invoking (foo "hello") should print 'a-number, but if I would use a named-lambda for the method function as suggested, foo would be locally redefined as a different function, and we would get an endless loop.


Best,
Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium










More information about the ecl-devel mailing list