From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#26073: workaround Date: Mon, 20 Mar 2017 10:04:16 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: blaine.gmane.org 1490000726 7295 195.159.176.226 (20 Mar 2017 09:05:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Mar 2017 09:05:26 +0000 (UTC) Cc: 26073@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Mar 20 10:05:19 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cptFY-0000dT-NP for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Mar 2017 10:05:12 +0100 Original-Received: from localhost ([::1]:59933 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cptFe-00074Q-G4 for geb-bug-gnu-emacs@m.gmane.org; Mon, 20 Mar 2017 05:05:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cptFV-00072H-I0 for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2017 05:05:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cptFP-00049a-LN for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2017 05:05:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37675) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cptFP-00049V-HE for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2017 05:05:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cptFN-00082h-Ln for bug-gnu-emacs@gnu.org; Mon, 20 Mar 2017 05:05:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 20 Mar 2017 09:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26073 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26073-submit@debbugs.gnu.org id=B26073.149000066430870 (code B ref 26073); Mon, 20 Mar 2017 09:05:01 +0000 Original-Received: (at 26073) by debbugs.gnu.org; 20 Mar 2017 09:04:24 +0000 Original-Received: from localhost ([127.0.0.1]:35874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cptEm-00081p-7u for submit@debbugs.gnu.org; Mon, 20 Mar 2017 05:04:24 -0400 Original-Received: from mail-pg0-f47.google.com ([74.125.83.47]:36273) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cptEk-00081d-BB for 26073@debbugs.gnu.org; Mon, 20 Mar 2017 05:04:23 -0400 Original-Received: by mail-pg0-f47.google.com with SMTP id g2so73818045pge.3 for <26073@debbugs.gnu.org>; Mon, 20 Mar 2017 02:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NIskUCYAiF4mG5gy9joPkLg8IQWewg/ogiiUqpSeHHU=; b=YnaI/kw9tmOR/2phvGcV0WtvPcQjLYmKPh0MKSsiX2qsZqttwUQWn8a1yjqkeJ0hrE AECygUxpHFIIlqN6ykqnnPESiTQP4XKbDGWa0Rq/P82y2jEUVoXzWfqyHMgGmHBgSsQv zVhHy4OEFHrnI2nS94D2LWIa27vHwFI6IJx29tSrAfFcO8BRb07veuxd3/u/YnO2fOwy /vWAk+Fv1bOa3zDgyU/cyeie4jMOBaAC3uay+ZU8kfUOIxrZz7onKPjgxgw9pShqow4w Z2VZsv/+hPiTnojbX0N9+Fgow5+2xQxg/Rnr3a5pshBI+7AtRcBttN7wnH7Xbc3ihcKL V3Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NIskUCYAiF4mG5gy9joPkLg8IQWewg/ogiiUqpSeHHU=; b=qYexT5MCmiC4wk5W74YnvcYTOlzwfcZdWXz8FxAnPYdTtXH4nmO7d6EX3TWfqEmvhq zPEXywPU4L2aCeSstc6C3FnFkzu2o9Pp0oMb7Zx3eoO9Ze9f+lVUAg/LMsxxLGUm9bla 4KtesofTZChi38LHV+C7hO8rIYuuxlLV/Yu15cvqREGhKNrbugSc+P4bwwj2Qg6+KEul OXrNKP6X/91qc4qHS7Z5j0vNedz3+ZlpqsVpQUvMOXuHS3ivBjVZ0vgfJ/pytBvz6YgM s/jDDLElIb8WHDQjrswl2wYhYiVweshwbEadxVY0NE2xx0lPDzGSWFZ0VotgrC62QV5f SeZA== X-Gm-Message-State: AFeK/H1e21pyHldwondJoaxGh74QfbquFoZTfrj7yFcyMjCclKhOCitBrwzlSQnLuTXjd36676xtfNhOqRn8XA== X-Received: by 10.98.196.12 with SMTP id y12mr31332659pff.49.1490000656615; Mon, 20 Mar 2017 02:04:16 -0700 (PDT) Original-Received: by 10.100.138.13 with HTTP; Mon, 20 Mar 2017 02:04:16 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:130746 Archived-At: > I'm wondering why generator.el uses cl-symbol-macrolet like that Because that's how it works. It needs to store variables in an outer scope so that their values are preserved between calls to `iter-next' on the same iterator. Therefore it "rebinds" local variables to different symbol and declares those symbols in outer scope, so that they become non-local variables captured by resulting closures. It's not a problem within generator function builder, rather it's a bug in in `cl-symbol-macrolet' that incorrectly applies `bindings' to forms with lambdas. The bug is that it rebinds variables even inside `lambda', not realizing that they (at least in lexical scope) are shadowed by the lambda's arguments. In comparison, it does handle shadowing with `let' properly. Paul On 20 March 2017 at 01:49, Stefan Monnier wrote: >> Attached patch is a workaround for the bug. It adds special handling >> of lambdas to `cl--sm-macroexpand', similar to the way it handles >> `let'. However, there is an unhandled case of "binding" symbols to >> forms. I'm also not sure what would be correct behavior in old >> non-lexical-scope code (do we still care?). > > Hmm... I'm wondering why generator.el uses cl-symbol-macrolet like that, > but indeed the precise behavior of cl-symbol-macrolet is currently > a bit fishy. > > > Stefan