Re: [cmucl-imp] PCL::*OPTIMIZE-GF-CALLS-P* bug when GF name is shadowed lexically
On 2/18/10 8:49 PM, Madhu wrote:
CMUCL does not correctly handle FLETs in DEFMETHOD bodies which use the same name as that of the generic function. An example might be:
; (setq pcl::*optimize-gf-calls-p* t) (defmethod foo (bar var) (format t "GENERICFOO ~S, ~S.%" bar var))
(defclass fnarr ()())
(defmethod foo ((bar fnarr) var) (flet ((foo (&optional arg) (foo var (class-of arg)))) ; gf FOO call (foo bar))) ; local function FOO call
;; (incorrect) Error when evaluating (foo (make-instance 'fnarr) t)
Perhaps the immediate symptom can be treated in WALK-METHOD-LAMBDA as follows? -- Madhu
I'm not familiar with PCL at all, but that looks reasonable. I'll check it in shortly. Ray
|X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham | version=3.2.5 |DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; | d=gmail.com; s=gamma; | h=domainkey-signature:received:received:message-id:date:from | :user-agent:mime-version:to:cc:subject:references:in-reply-to | :x-enigmail-version:content-type:content-transfer-encoding; | bh=HbEfdRttazBaNje4REulqpPOEMOg/rgeqaLNq9800pw=; | b=Wfm7WI0AJqn8CKbGoRKdDZSwuAJ8Uo5g/wi9iOgcF1jXN6kuNkwpMklY4IspyvBIQ0 | cK4F3Hx0E6JVBtfdSTkDPbxoI/RMZg5R1i1RVXVTdkZa4IhRHydUoI+8hLra0fBAIL6F | Sx4muc6ZU9UvO1HQKpzvphAOorW5v1AXUsdmY= |Date: Thu, 04 Mar 2010 07:52:53 -0500 |From: Raymond Toy <toy.raymond@gmail.com> |MIME-Version: 1.0 |CC: cmucl-imp@cons.org |Content-Type: text/plain; charset=ISO-8859-1 | |On 2/18/10 8:49 PM, Madhu wrote: |> CMUCL does not correctly handle FLETs in DEFMETHOD bodies which use the |> same name as that of the generic function. |> An example might be: |> |> ; (setq pcl::*optimize-gf-calls-p* t) |> (defmethod foo (bar var) (format t "GENERICFOO ~S, ~S.%" bar var)) |> |> (defclass fnarr ()()) |> |> (defmethod foo ((bar fnarr) var) |> (flet ((foo (&optional arg) |> (foo var (class-of arg)))) ; gf FOO call |> (foo bar))) ; local function FOO call |> |> ;; (incorrect) Error when evaluating |> (foo (make-instance 'fnarr) t) |> |> |> Perhaps the immediate symptom can be treated in WALK-METHOD-LAMBDA as |> follows? -- Madhu |> | |I'm not familiar with PCL at all, but that looks reasonable. I'll check |it in shortly. | |Ray (I'm getting back to email in after a long vacation from the computer) I dont think these 2 fixs got checked in, from grepping the commit list. -- Regards Madhu
On 4/21/10 10:11 PM, Madhu wrote:
|X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham | version=3.2.5 |DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; | d=gmail.com; s=gamma; | h=domainkey-signature:received:received:message-id:date:from | :user-agent:mime-version:to:cc:subject:references:in-reply-to | :x-enigmail-version:content-type:content-transfer-encoding; | bh=HbEfdRttazBaNje4REulqpPOEMOg/rgeqaLNq9800pw=; | b=Wfm7WI0AJqn8CKbGoRKdDZSwuAJ8Uo5g/wi9iOgcF1jXN6kuNkwpMklY4IspyvBIQ0 | cK4F3Hx0E6JVBtfdSTkDPbxoI/RMZg5R1i1RVXVTdkZa4IhRHydUoI+8hLra0fBAIL6F | Sx4muc6ZU9UvO1HQKpzvphAOorW5v1AXUsdmY= |Date: Thu, 04 Mar 2010 07:52:53 -0500 |From: Raymond Toy <toy.raymond@gmail.com> |MIME-Version: 1.0 |CC: cmucl-imp@cons.org |Content-Type: text/plain; charset=ISO-8859-1 | |On 2/18/10 8:49 PM, Madhu wrote: |> CMUCL does not correctly handle FLETs in DEFMETHOD bodies which use the |> same name as that of the generic function. |> An example might be: |> |> ; (setq pcl::*optimize-gf-calls-p* t) |> (defmethod foo (bar var) (format t "GENERICFOO ~S, ~S.%" bar var)) |> |> (defclass fnarr ()()) |> |> (defmethod foo ((bar fnarr) var) |> (flet ((foo (&optional arg) |> (foo var (class-of arg)))) ; gf FOO call |> (foo bar))) ; local function FOO call |> |> ;; (incorrect) Error when evaluating |> (foo (make-instance 'fnarr) t) |> |> |> Perhaps the immediate symptom can be treated in WALK-METHOD-LAMBDA as |> follows? -- Madhu |> | |I'm not familiar with PCL at all, but that looks reasonable. I'll check |it in shortly. | |Ray
(I'm getting back to email in after a long vacation from the computer) I dont think these 2 fixs got checked in, from grepping the commit list.
Look at rev 1.74 of pcl/boot.lisp. Ray
|Date: Thu, 22 Apr 2010 12:57:42 -0400 |From: Raymond Toy <toy.raymond@gmail.com> | |> |I'm not familiar with PCL at all, but that looks reasonable. |> |I'll check it in shortly. | |> (I'm getting back to email after a long vacation from the |> computer) I dont think these 2 fixes got checked in, from |> grepping the commit list. | |Look at rev 1.74 of pcl/boot.lisp. Thanks, I was expecting to see an additional second fix in WALK-METHOD-LAMBDA to deal with the code path that handled APPLY; but it appears that that fix is not required after all (for my use cases at least). -- Madhu
On 4/24/10 3:36 AM, Madhu wrote:
|Date: Thu, 22 Apr 2010 12:57:42 -0400 |From: Raymond Toy <toy.raymond@gmail.com> | |> |I'm not familiar with PCL at all, but that looks reasonable. |> |I'll check it in shortly. | |> (I'm getting back to email after a long vacation from the |> computer) I dont think these 2 fixes got checked in, from |> grepping the commit list. | |Look at rev 1.74 of pcl/boot.lisp.
Thanks, I was expecting to see an additional second fix in WALK-METHOD-LAMBDA to deal with the code path that handled APPLY; but it appears that that fix is not required after all (for my use cases at least).
Yeah, I couldn't find any simple examples where APPLY had this problem. Perhaps I didn't try hard enough.... Ray
participants (2)
-
Madhu -
Raymond Toy