|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