On 25 Feb 2010, at 15:32, Juan Jose Garcia-Ripoll wrote:

On Thu, Feb 25, 2010 at 3:20 PM, Pascal Costanza <pc@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?


Pascal

-- 
Vrije Universiteit Brussel
Software Languages Lab
Pleinlaan 2, B-1050 Brussel, Belgium