[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