From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Nov 2022 01:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 59140@debbugs.gnu.org Cc: okamsn@protonmail.com X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16679569903723 (code B ref -1); Wed, 09 Nov 2022 01:24:01 +0000 Received: (at submit) by debbugs.gnu.org; 9 Nov 2022 01:23:10 +0000 Received: from localhost ([127.0.0.1]:38448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osZo5-0000xz-TT for submit@debbugs.gnu.org; Tue, 08 Nov 2022 20:23:10 -0500 Received: from lists.gnu.org ([209.51.188.17]:58728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osZo4-0000xs-Hn for submit@debbugs.gnu.org; Tue, 08 Nov 2022 20:23:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osZo4-0003RT-Cs for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2022 20:23:08 -0500 Received: from mout.web.de ([217.72.192.78]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1osZny-0001dC-Gz for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2022 20:23:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1667956977; bh=kZ30HP4hkQ7lTeqGiUp2mVTVImDghEYOYs2bMUZt6ok=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date; b=c9RUWiyQluQqags+/mbrMWTdOCV8xLu2KU70Jtj84eRspXkCgPeW81oWyptsTNgpz uORFf0JcWQ50gtAyzq2G4iCbsLRhlW7+jZl7kG17JiY8WaiVWOviy2NUz31hL35/TC 7rTZLCFECVdR/vpkCy6gZCNoTVjmBnHGIqf6vPjpDdofzf+N6QipvALZXxqJvwOctT tb1KX5SQZwkM1UEBI7c7qxLUofZrVsdgkbiBCMjGsisV3sWPysx6dBlcq9gtHZYC9o AIE6iIhaF1J9AltH/SDXuBjvMaDhS5FbKbjdCxJ+BHV3Wyq9e8l24ZVkVNi6UH1XYt fRyCMA+A5rJZQ== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([88.66.71.129]) by smtp.web.de (mrweb105 [213.165.67.124]) with ESMTPSA (Nemesis) id 1N79N8-1p4wg92IFY-017fPO; Wed, 09 Nov 2022 02:22:57 +0100 From: Michael Heerdegen Date: Wed, 09 Nov 2022 02:22:56 +0100 Message-ID: <87sfissyz3.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:iWZZ5Tqy/6hOAzVnXwGDge0US8p5djHL+aR96aosEquoH1Hs5ev wqCjIHzGq1muJjkgYj636pNKjDUnyRCy06hFHd3lOY2xh2/qdy7YMkTR0LZj2N2dFpQlh41 WRT5R5eFFDa0z8L/owOt+M9ypdAo/nBI1eY+vAoOySHFp6WjChV6FQ0zB9na/+yxksUpb9v pZJbKdvJwQtP9IMFh3kPg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:D+eria/AiwQ=;Pxt+wrWuGh07Q71m8cNQf7qcvU9 dKBhgL35dVwg70bj2aBGqFwNgG6/Z0SCuj41rj1kW9AfhbyupGsGohQr5fDOx7w24v5G2oYzc Ov0BfWwO82N2LhnxqmRqgIxWuP/CdlSZfdqmLZB3ANO0KBvEJYs2aQNPmSdtTED9EBMRNq8QF QRZeD3DJrnGwNpPdX+GEtziIBwujspOqCRMKjdPc+CUyAlKHPZOWpJhGLQ3tf6HQoSJS68k1X utFDXAvit+1EEn/h7GOLcyfoIQLWK7a8lqXDfG0KHSWMg3Dm5bgCSL2szNgf8cTpQRWpQxgYr hYx7zXTx4eX5bICoSuApWEqGFuRwQRgIp2BnyyToMUgdrDEdRPeL8C0jYirXt3SBMeSgOA5x9 VMLImpW5a7juWpTyfM/uqknI0a1XkfNOnJi56AoUtQI9auQc0jFumPztrHX9Y8iNd37h3KNM7 i/BOM6Wr8E0rnBr6H+IrecIUKOv+Ze0YHEcVyMxLTk768fzH7QEyLMOl3G2gMqssvRkty/8JN Pc8K97w9fvm7v05eq03tEcG9tEaDehBHP9v42FVDWlsBdxaRr68We2m9wRPBj71IMvZa50G9Z 0LTkFoz+9bFPQNd26UqI+e/VF6jnI9g4hzEv3A2kTkEpy/c2UifZa5ARF74XbXGdZAJfDGMvi eDagp+/cO4FKgWIB6a9i3CxrQRfkzhusCp4O9m1rbPQeo8zo7OJfHztv09MU0PWqAv78HTKy0 Y3tCWK0DcSHjxuIk0ZwfDOCCD700+l6jUe9eqdJx+ILycKtfMjJpg5QY/Xjg3s02PKg5Yv30g YyxdGrkBj/ovNTGYdKokbnmFfY3Gswf/FgkCgZ2gUbQmpvyXbsC+Rc2/8GwaSctxikr5ZInUB l+kNr/G/J67L0HkHjmME5vC9Lr9gtIod/xikchULRD2Sk9sKzyB6EWSRk3mYWi7nvNe4ch6NJ Encimu3jko9Gmaj0i3EnLHMlkLw= Received-SPF: pass client-ip=217.72.192.78; envelope-from=michael_heerdegen@web.de; helo=mout.web.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, In emacs-help (Okamsn ) it has been pointed to the issue that `iter-yield' (from generator.el) is not supported in some contexts - contexts where yielding happens from inside a lambda expression or directly (like here when mapping over a sequence), e.g. (setq iter-maker (iter-lambda (x) (seq-doseq (item x) (iter-yield item)))) (setq my-iter (funcall iter-maker '(1 2 3))) (iter-next my-iter) ~~> (void-function cps-internal-yield) (seq-doseq expands to more or less just mapc+lambda) or (setq iter-maker (iter-lambda (x) (seq-do #'iter-yield x))) (setq my-iter (funcall iter-maker '(1 2 3))) (iter-next my-iter) ~~> (error "=E2=80=98iter-yield=E2=80=99 used outside a generator") These examples are written correctly but seem to hit an undocumented limitation of the implementation in generator.el I quote Stefan Monnier answering what should be done: > IIRC, one of the main limitations of `generator.el` is that it doesn't > handle `lambda` (and neither should you use `#'iter-yield`, IIRC). >=20 > I don't really know how to go about fixing it. >=20 > A good first step would be to make sure it emits an error (or a warning) > when you use `#'iter-yield` or when you call `#'iter-yield` from with > a lambda expression. TIA, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 12 15:23:11 2022 Received: (at control) by debbugs.gnu.org; 12 Nov 2022 20:23:11 +0000 Received: from localhost ([127.0.0.1]:49086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otx1y-0002Dx-RR for submit@debbugs.gnu.org; Sat, 12 Nov 2022 15:23:11 -0500 Received: from mail-ot1-f51.google.com ([209.85.210.51]:33583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otx1w-0002Di-SK for control@debbugs.gnu.org; Sat, 12 Nov 2022 15:23:09 -0500 Received: by mail-ot1-f51.google.com with SMTP id 46-20020a9d0631000000b00666823da25fso4658890otn.0 for ; Sat, 12 Nov 2022 12:23:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=FAg7FyL9DDVKXOZrDWRwq58mg3hcyHYyHyXOj6VbgNY=; b=TD7Vi1RTnvoWG61bcBAv231VNkOOp0Hj6dkGeYdS4HN6GCWlbcxyzd4tVadsMrGQFW cSESXZPhl6lPHgQRFYIL3KnK2Alz0WGwgGuP9Fo4y28ntowmFeXKLMskyjpNb1XcQp/y fyG6rzlwl4dNfDQ/js73V1tld3CZlxk6D2KGfMmyMYfCF/z1LICk/e9TANS4V+CsykXw Bi87PZSsIhDkGNZ34JnpcEb+Gx7qbzmhDMppqbPMsRiFCngv9vwXEu45ObkF5qatnvGE NJpI1EDb2Csw7wsWxYMXevXPnABjajOCGUwGwv/XeCAt+4ntKvz+SOtzAOJq/ruBd4R0 ZgSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=FAg7FyL9DDVKXOZrDWRwq58mg3hcyHYyHyXOj6VbgNY=; b=Qg08xJk1BpdYm0v48SuAYlfYDP9UdId7dEO2ZBcxCKfdkfpQ9IdZRkcslt53mmxbK8 m1XLl3h9x9GOiV5J+oMVMTl+EQGboFh0KNu42SVBzoBznrZIMF/Hdm7GuIZGNl9ZK2hK Ts2FPyPYS+DTB5KD0Pm4d6xTb8FteUqCYrwDSb7ESboumPkl50gfZqCk8tAcfW07rkIZ PKwXG+uDSkoNhKw/UVRJOCXid4zlk9pvcq6JCsa89n8QwhFLyxvKMtN/Wm8pRolKct8Q yOO9U04uB+4Dg7/jpDYmvOR1WruuwIMHtFMW6qjZtWRes4CyYuEu1Q6Xg3g6J5NFsRir chhQ== X-Gm-Message-State: ANoB5pkhX42Y3k0jMenr6HrwXvMbkvM2U/Htyu+I3RzNfKuBVjBlT/5g c3YNRM9U5ZsGiUXfKVuHGeuzpNj9/wAvGmfz6f1mWMdh X-Google-Smtp-Source: AA0mqf6bv7QG00p1aNp0h+UcuAPhHP2JDP4u5NjPPvRK8qvvGM/io3u5Rm/FCqGQJOLsu/x6QOe4p5b1aTev2EWHoQo= X-Received: by 2002:a9d:4f10:0:b0:66c:5232:b9d1 with SMTP id d16-20020a9d4f10000000b0066c5232b9d1mr3712577otl.224.1668284583199; Sat, 12 Nov 2022 12:23:03 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 12 Nov 2022 12:23:02 -0800 From: Stefan Kangas X-Hashcash: 1:20:221112:control@debbugs.gnu.org::fN0lT/10HwgvIttn:1oCX MIME-Version: 1.0 Date: Sat, 12 Nov 2022 12:23:02 -0800 Message-ID: Subject: control message for bug #59140 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 59140 wishlist quit From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Max Brieiev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Sep 2023 19:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 59140@debbugs.gnu.org, okamsn@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 59140-submit@debbugs.gnu.org id=B59140.169480778531795 (code B ref 59140); Fri, 15 Sep 2023 19:57:01 +0000 Received: (at 59140) by debbugs.gnu.org; 15 Sep 2023 19:56:25 +0000 Received: from localhost ([127.0.0.1]:44890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhEvR-0008Gl-89 for submit@debbugs.gnu.org; Fri, 15 Sep 2023 15:56:25 -0400 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:54719) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhEvO-0008GU-Ld for 59140@debbugs.gnu.org; Fri, 15 Sep 2023 15:56:23 -0400 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5308430052fso1360071a12.1 for <59140@debbugs.gnu.org>; Fri, 15 Sep 2023 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694807770; x=1695412570; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3wVqfX0+8W58wQwV/gp9B7gUvV+772/K8ppDISKj2r4=; b=OH/5LXIAPcT2oDyUuRirEeMKqzZ0yGbm3UI7LbOqI8+QwcU77y1zXIVNyftFUR+/Dk /YpIn41IRRE5lMX1vB6SzS1sjAwLO5cWDsfuvQDasJsKXMc2x3EZWuaGmrWz4bI10OVA Asxqr127SXjp+4NgklJfLVAVi2EyCyQJd8KKp2OgnllACK7XwrNeW6qDL2usyBeNeAiq Ve1ZbgNeg8TCMdc+TxM2VEsi36Ujjsc/wtfAJJ71XWn2Y/DHg3hXrrvjJX3UwVRj2x+1 O6BfAgDvGEQL/FCMmGWPBBn8fP2D0ttdX9Dg0jrrd8UuHSW6oiKEJOa/Ab75LD1k6cDQ hN/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694807770; x=1695412570; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3wVqfX0+8W58wQwV/gp9B7gUvV+772/K8ppDISKj2r4=; b=JER1EN2rnKQxTjjn94AhQZOGPhPHwnOUQ3v4/3gtoPBHlRlgaTtQdqQ4Ek0InW7K+d TyiJf+4F2u4COOLHpIeNDG72eyAVS0vif36ofiW4ObTJ8HfFlXZZXwckJ9Ts+/R9/CRW ImgcR/ZK50XKk9Wgtvtkb75nkYLKdloW/v6KzLi9INkPzBs62RUcGoum1h9IQwCqKABH Nla9GNeZEUvHGQeL6zWYqf0a3R+E22BZ6hcSQbliY2ieVguLkXCPCJc54yA9n+kiHSAW DiCyRNO31VqaXvF8iLUrTM6QSFy1Vk/uGR3W/KULllLCDf5vQQQLhMsuFjjc22qokKAA r/IA== X-Gm-Message-State: AOJu0YzEmC07dR4FSCb3TAPRyGP7iOAdC1g8nMtJpDBwM13bbgr+GG1Z ClbZXVllwpcYBcY5qzhpvtEeIyuHxQE= X-Google-Smtp-Source: AGHT+IEC0jTGJG+PiAJJjW7KI31dxX2hwfvrtPhFvyIGMJKLqdqjRdXoWiut63DZsvVwFNS1+AYWVg== X-Received: by 2002:aa7:dcc6:0:b0:525:69c8:6f51 with SMTP id w6-20020aa7dcc6000000b0052569c86f51mr2154362edu.35.1694807769859; Fri, 15 Sep 2023 12:56:09 -0700 (PDT) Received: from vmax ([109.251.233.9]) by smtp.gmail.com with ESMTPSA id y2-20020aa7c242000000b0052a404e5929sm2646606edo.66.2023.09.15.12.56.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Sep 2023 12:56:09 -0700 (PDT) From: Max Brieiev In-Reply-To: <87sfissyz3.fsf@web.de> (Michael Heerdegen's message of "Wed, 09 Nov 2022 02:22:56 +0100") References: <87sfissyz3.fsf@web.de> Date: Fri, 15 Sep 2023 22:56:07 +0300 Message-ID: <87v8cb9pns.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Hello, > > In emacs-help (Okamsn ) it has been pointed to > the issue that `iter-yield' (from generator.el) is not supported in some > contexts - contexts where yielding happens from inside a lambda > expression or directly (like here when mapping over a sequence), e.g. > > (setq iter-maker (iter-lambda (x) > (seq-doseq (item x) > (iter-yield item)))) > (setq my-iter (funcall iter-maker '(1 2 3))) > (iter-next my-iter) > > ~~> (void-function cps-internal-yield) > > (seq-doseq expands to more or less just mapc+lambda) or > > (setq iter-maker (iter-lambda (x) > (seq-do #'iter-yield x))) > (setq my-iter (funcall iter-maker '(1 2 3))) > (iter-next my-iter) > ~~> (error "=E2=80=98iter-yield=E2=80=99 used outside a generator") > > These examples are written correctly but seem to hit an undocumented > limitation of the implementation in generator.el > > I quote Stefan Monnier answering what should be done: > >> IIRC, one of the main limitations of `generator.el` is that it doesn't >> handle `lambda` (and neither should you use `#'iter-yield`, IIRC). >>=20 >> I don't really know how to go about fixing it. >>=20 >> A good first step would be to make sure it emits an error (or a warning) >> when you use `#'iter-yield` or when you call `#'iter-yield` from with >> a lambda expression. Is this unfixable in principle or the fix is just hard (non-obvious)? If iter-yield is lexically scoped within lambda expression, then could the lambda possibly be replaced with the iter-lambda? For example, this: (iter-defun my-generator () (funcall (lambda () (iter-yield 5)))) would be expanded by iter-defun macro into this: (... (let ((gen (iter-lambda () (iter-yield 5)))) (iter-next (funcall gen)))) Does it make sense? From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Sep 2023 22:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Max Brieiev Cc: Michael Heerdegen , 59140@debbugs.gnu.org, okamsn@protonmail.com Received: via spool by 59140-submit@debbugs.gnu.org id=B59140.169481635414650 (code B ref 59140); Fri, 15 Sep 2023 22:20:01 +0000 Received: (at 59140) by debbugs.gnu.org; 15 Sep 2023 22:19:14 +0000 Received: from localhost ([127.0.0.1]:45037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhH9d-0003oE-SW for submit@debbugs.gnu.org; Fri, 15 Sep 2023 18:19:14 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55884) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhH9c-0003o1-4h for 59140@debbugs.gnu.org; Fri, 15 Sep 2023 18:19:13 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A0906805A9; Fri, 15 Sep 2023 18:18:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1694816338; bh=yfmM1dmNlHY4ISl46/2g9k7jBooA11RpjSW2tOjC7CA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RtIaRyk1a5T6NJelFedz9ohOnpLVbpi47wsEa/ehBbZW5QrZm81CxMX4LsENVziHS 3Fq84UF8/tGUMUWebPmfbDsRmOvMLalpeOPm8no18GUgGqgP9YnzcXc7SM3GhPccJW u4yYaA6PFZQGPgtU7PpBofhq/nKw1ycxdIBR+MbMT/rr7bW2x8lEMmhD4F5Hfkc7z0 C43sY8GRZ2IrE0q05NEOTHNee8NEcfWw/m2HQorZngesuyyZGQM+zVtHn7dSdLsvOD 7KF1E9DYPboEICDn0FfrEJclRrJUQGNmffQCSi5C9LTdPO4jF8MkapZUNfk371PCVk SHqBPwkgMZfEg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 51C4C803B1; Fri, 15 Sep 2023 18:18:58 -0400 (EDT) Received: from pastel (unknown [104.247.237.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E0FC5120009; Fri, 15 Sep 2023 18:18:57 -0400 (EDT) From: Stefan Monnier In-Reply-To: <87v8cb9pns.fsf@gmail.com> (Max Brieiev's message of "Fri, 15 Sep 2023 22:56:07 +0300") Message-ID: References: <87sfissyz3.fsf@web.de> <87v8cb9pns.fsf@gmail.com> Date: Fri, 15 Sep 2023 18:18:56 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.122 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>> IIRC, one of the main limitations of `generator.el` is that it doesn't >>> handle `lambda` (and neither should you use `#'iter-yield`, IIRC). >>> >>> I don't really know how to go about fixing it. >>> >>> A good first step would be to make sure it emits an error (or a warning) >>> when you use `#'iter-yield` or when you call `#'iter-yield` from with >>> a lambda expression. > > Is this unfixable in principle or the fix is just hard (non-obvious)? To do its job, `generator.el` performs a kind of CPS (continuation passing style) conversion. Such a conversion can be made to handle "the whole language" fairly easily, but at the cost of being unable to interact seamlessly with code which has not gone through the same transformation. So, yes, in principle it can be fixed *if* we make every single chunk of ELisp code go through that transformation (plus adjust accordingly all the primitives implemented in C). Since that's not an option, `generator.el` uses a "local CPS conversion" but these can't handle higher-order functions in general because they need to be able to determine easily what is "local" and first-class functions give you way to much power to play with the control flow. So in practice it's not fixable. > If iter-yield is lexically scoped within lambda expression, then could > the lambda possibly be replaced with the iter-lambda? Yes, if you can determine *all* the places from where this lambda can be called and if you can then also change all the other lambdas that can be called from one of those places, plus all the places where those other lambdas can be called, plus all the other lambdas that can be called from those other places, etc.... :-( Stefan From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 01:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Max Brieiev Cc: 59140@debbugs.gnu.org, okamsn@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 59140-submit@debbugs.gnu.org id=B59140.16948294225650 (code B ref 59140); Sat, 16 Sep 2023 01:58:01 +0000 Received: (at 59140) by debbugs.gnu.org; 16 Sep 2023 01:57:02 +0000 Received: from localhost ([127.0.0.1]:45125 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhKYP-0001T4-OS for submit@debbugs.gnu.org; Fri, 15 Sep 2023 21:57:01 -0400 Received: from mout.web.de ([212.227.15.4]:45343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhKYK-0001SV-7f for 59140@debbugs.gnu.org; Fri, 15 Sep 2023 21:57:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=s29768273; t=1694829397; x=1695434197; i=michael_heerdegen@web.de; bh=4EUYaTXKZf2+Lxz1D0YTIFS3IhxoEyujvZqoZ4Rzehc=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date; b=cZXRf1xj3IyjPue9/0a/XNnv/ZcDN9SAqHsMmwuYLNbYCN/MqBY55YCN9hAVhr669BZlvcuy1GF TA+MwCM0FLT+LBOqfuO6si0w82vw6kpLdn28XtxhQ34sjDfFGfgZCvGYb+aducPMk78V7BKr2AOqw h3EAdjJw5qYLRoIPgbWpV/nvX8I3S1qTnfabIRaA7eQ+jNjNETrY1t9eIgIeRskaU9ZL3PfTOcfrl dMuAuFlv1YNx23KcLcSSXxeV1CXaJprgjPb2+T++ZG1fYHtPDuAJ0I56vpWaqsoZZGESpp0jyuOWd cuFhfnk8WdkqPRXSQcAIqcAoxwROK2TtjQww== X-UI-Sender-Class: 814a7b36-bfc1-4dae-8640-3722d8ec6cd6 Received: from drachen.dragon ([88.66.201.191]) by smtp.web.de (mrweb006 [213.165.67.108]) with ESMTPSA (Nemesis) id 1MjBRZ-1rJiAC2gnV-00eu47; Sat, 16 Sep 2023 03:56:37 +0200 From: Michael Heerdegen In-Reply-To: <87v8cb9pns.fsf@gmail.com> (Max Brieiev's message of "Fri, 15 Sep 2023 22:56:07 +0300") References: <87sfissyz3.fsf@web.de> <87v8cb9pns.fsf@gmail.com> Date: Sat, 16 Sep 2023 03:56:35 +0200 Message-ID: <87cyyianjg.fsf@web.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:q7m0pYm61hjCSyxT8IyLzMqYAEcu72PZQdA6lf1QD/2cQjlA56F tID4cCUEJkcSz+AQBE4AAmanFYYhpDBYSXmLB/uKCspcmBxHKKvW29R2jCrAm9EYIVHu6vl vE2zEi/ie1Cq4YIIXT9EAxatDN9htNiQ5G0kuAckmyf9o4v0L2pNmPa2Mp6nIJZsasIg7g4 OcmyQlmvWDam4m3tY71wg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:6CwVe5PNvk4=;ElTuW399Gx6uK9V0f+HnYEvzvxB FZi9bYvAEYtcJy8kibh/FWf3L2AtcYzv9RmOuE/17doV4hZYnKdHq4PL6BOnlCEiSoppr51EK yBqoUtIiqvR+eL1SMShuQpKwRBNI4/uzP1KmnpgCDdp8Vr5BcM9SLUBXP6fvKHaXpiS0b0k9f Y62lWu5k7TZ3G/fxs7f1dfJnCnwRgT5BeosCIp2TTexUvjPc9248wCMUAv/zzZess7BhkKnOy z0FWuIAXodC1cc/ge1qQkrkngAxiAZ/NovVVEQrAT4hUV5sWAhPNv7GZj2vILD3Fw+SJUhA+k XcGdKIfloJnEpFGByMcsMOkTWUy7VzohyBNufPCkAlWeBF7+RL+YkVJVve7hbbAs061UR6Bum Ygpyv3QCQ+wUZqmBb/Pc0PbsmADjKddsmra+QSTsx65htyc12K8hj+PjGpZIYocTuVq1wanjQ RWpY071Uv9CaxLXCmPcHLfbm7NuB2wFQsAqZK7oX8qdmvM9St4/XLt9+SgtwginqUDYVFI4QX t5wp4c8unPTpDXpT+D5VMUW7WPHMUnV2bEaDMONVmcI1PBwIlFneTcpYqS0tz+GHVwXfYhn+N ibnoFs4cevULwhHvayFevlZUmHaD5fKDwPBf6G8LlYRAJnIng8l7u4xlbTBeZJ+utez9E8Ve3 FrBN7zcnGWpGUqtQar0SaDyGwiEkk/5PNqBMObM/YeZUTmL6WGeqEJkXFw6pkviuQIEcuaz7d rz0aKRuNhVxx7qlqPl+DFRvuYCCFs/AcLPjKiup1TwIrRdo1XqpLsE30TzEzRA6XD/lmSffib +Titne7Z6cAnaEkgyf+bxhcHeSfxcYpBfRwIyi3bIzXPcwRJgRTcsuYQUbh5NRvKKpC6GlIe2 1a+l3hX0UgA2DFrVwXHyJlrsIyCinPc3eTO29Qtn+YCeJKwg1QRLHGJEKUh4qMVHv/pdVspyp MeBHxiFzPRzQL7aA7vl0aqZMimA= X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Max Brieiev writes: > For example, this: > > (iter-defun my-generator () > (funcall (lambda () (iter-yield 5)))) > > would be expanded by iter-defun macro into this: > > (... > (let ((gen (iter-lambda () (iter-yield 5)))) > (iter-next (funcall gen)))) > > Does it make sense? Does it? Isn't the `let' expression equivalent to just `5'? With other words: you don't yield from an outside generator, as far as I understand (or am I wrong? what's the content of your "..."?). Michael. From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Max Brieiev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 19:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 59140@debbugs.gnu.org Cc: michael_heerdegen@web.de, okamsn@protonmail.com, monnier@iro.umontreal.ca X-Debbugs-Original-To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" X-Debbugs-Original-Cc: Michael Heerdegen , 59140@debbugs.gnu.org, okamsn@protonmail.com, Stefan Monnier Received: via spool by submit@debbugs.gnu.org id=B.169489318632381 (code B ref -1); Sat, 16 Sep 2023 19:40:01 +0000 Received: (at submit) by debbugs.gnu.org; 16 Sep 2023 19:39:46 +0000 Received: from localhost ([127.0.0.1]:48559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhb8r-0008QD-Ca for submit@debbugs.gnu.org; Sat, 16 Sep 2023 15:39:45 -0400 Received: from lists.gnu.org ([2001:470:142::17]:52418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhb8l-0008Pg-V3 for submit@debbugs.gnu.org; Sat, 16 Sep 2023 15:39:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qhb8Y-0000NJ-TD for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 15:39:26 -0400 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qhb8V-0002zt-JI for bug-gnu-emacs@gnu.org; Sat, 16 Sep 2023 15:39:26 -0400 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-52bd9ddb741so4007750a12.0 for ; Sat, 16 Sep 2023 12:39:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694893161; x=1695497961; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=rXGXrsxbxsAdupdNnwsmlT6S+dNql0pQRJ6j2haGFIw=; b=VX8o3Yu0cM3rhMN5mvpDnhKW2PmWJR/lmHbtcpMREcjPzeDQm4H+timgJT7Vm7K9Pn ufxRaMoWKIRwyepCvAW0+1rYYeHsDzR4g58hQeIpvIQR73CKnK5xpB5sVarwPWylBTV9 Cmn/CQWUuN3UKoJeo/PX8EItcU5amrRJeJyEIPIiVI8LygCzs8JEr+Pee7gniQAgVxDx HF0Afxh+v3ZPrClTV65QEz5BesSO40rRBWMYPdEUPJa0f/mYULP6Mpui2brPgYn7vaoK SlN5dNoxMqyB82q9JTh5Xm7moJxSEJExBYXWixYvqz/ihNCMORm7UUmWMzLfneoIkHjS zWKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694893161; x=1695497961; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rXGXrsxbxsAdupdNnwsmlT6S+dNql0pQRJ6j2haGFIw=; b=sXuonX25ugDbv49Ih+UTAN4HVcKTulKhU/yMfCzAVoJ5W2HSoHzxhc1kVsiHt3AZUh /saQMIIQeEUU0f2zxWJitBYhXxkPPjaYG9fjt8X2XWiRD6vb6PZBtvwYGPf3GUyNiWnr lF43GoS3+Jd8rg2UXPcZPPqJO5r1KlzW1JPQVA/tj5TvqPUokWU7UdxtnmyCNxqFaOdE Xuv4FKGhph1OhZCcZChAL1IbV+1Pe2M/wrmRGX/GPQ4x/+NthTu1VM22nN1tsQRCo2IK +JH/t2KR8Ptu0BA1JwWYubmLqGWtMWW+1Uvhcj9+tKtMNgAGRGCXxBL+9V4rXddGedr3 0kQQ== X-Gm-Message-State: AOJu0YwoX8jtsGfmlpVD0vyz/fGUQVqPbK8uB5yEvT/EsNI58LqQxjUN TiUfrePI2k9OU8/EuPpRQzk= X-Google-Smtp-Source: AGHT+IHxL8bkX/RmZH36xFZ3jmIhHSZx9BP0oJav9KM4bsSPy5y0x36MiP0iBd0DKwhGaKvSKSeolg== X-Received: by 2002:aa7:d74b:0:b0:522:3ef1:b1d with SMTP id a11-20020aa7d74b000000b005223ef10b1dmr3458022eds.6.1694893161221; Sat, 16 Sep 2023 12:39:21 -0700 (PDT) Received: from vmax ([109.251.233.9]) by smtp.gmail.com with ESMTPSA id cm8-20020a0564020c8800b00530bc7cf377sm1236125edb.12.2023.09.16.12.39.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Sep 2023 12:39:20 -0700 (PDT) From: Max Brieiev In-Reply-To: (Stefan Monnier via's message of "Fri, 15 Sep 2023 18:18:56 -0400") References: <87sfissyz3.fsf@web.de> <87v8cb9pns.fsf@gmail.com> Date: Sat, 16 Sep 2023 22:39:18 +0300 Message-ID: <87r0mxaowp.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::534; envelope-from=max.brieiev@gmail.com; helo=mail-ed1-x534.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Since that's not an option, `generator.el` uses a "local CPS conversion" > but these can't handle higher-order functions in general because they > need to be able to determine easily what is "local" and first-class > functions give you way to much power to play with the control flow. So if I understand it correctly, "local CPS conversion" can't handle higher-order functions, because "locality" of the lambda function must be completely known (but it can't practically be known), otherwise we will have to traverse the whole language. I should had said that "plain lambdas" is not my concern though. I am fine with the fact that yielding from the lambda is illegal. My concern is that with the current state of affairs it is impossible to use many macros inside generator functions. Namely, `named-let` and `pcase` are an excellent examples of this: they are perfect companions for a generator to implement an infinite/lazy looping construct to match against incoming data, like a streaming parser and things like that. For example, (iter-defun iter-sum-string () (named-let sum ((result 0) (chunk "")) (pcase chunk ((rx string-start (let num (+ digit)) " " (let tail (* anything))) (sum (+ result (string-to-number num)) tail)) ((rx string-start "\n") result) (_ (sum result (iter-yield nil)))))) (setq it (iter-sum-string)) (iter-next it) ; advance it (iter-next it "5 17 8 ") (iter-next it "4 2 \n") Notice, that the above code does not visually appear to use any lambdas, but it fails, because internally it expands to lambdas, causing (void-function cps-internal-yield). Now, let's get back to the original problem - the fact that in "local CPS" the "locality" of the lambda must be completely known. If we look at `named-let` it appears to be completely self-contained: the control flow and the usage of higher order functions that it expands to is fully known due to the way it is encoded into the macro. So provided with this information, do we have enough information to perform a CPS conversion of the `named-let`? Similarly, in pcase, unless the handler is provided as a lambda by the user, the internal/expanded lambdas might be "local enough" to perform CPS conversion. What I am trying to say is that, if "local CPS conversion" of higher order functions is impossible to perform in general, then could we possibly make conversions on a macro per macro basis, when the macro is "local enough"? From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Sep 2023 21:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Max Brieiev Cc: Michael Heerdegen , 59140@debbugs.gnu.org, okamsn@protonmail.com Received: via spool by 59140-submit@debbugs.gnu.org id=B59140.169489992511772 (code B ref 59140); Sat, 16 Sep 2023 21:33:01 +0000 Received: (at 59140) by debbugs.gnu.org; 16 Sep 2023 21:32:05 +0000 Received: from localhost ([127.0.0.1]:48672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhctY-00033n-NA for submit@debbugs.gnu.org; Sat, 16 Sep 2023 17:32:05 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7386) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhctV-00033D-8L for 59140@debbugs.gnu.org; Sat, 16 Sep 2023 17:32:03 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 31731803EB; Sat, 16 Sep 2023 17:31:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1694899902; bh=5vw3ecTgNTTm3dDuZ1DYM9kJdCwyudbGnkpTLJulnzY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=a11r9E3iw5cT74tKwjkeCp/XhBlEELlZxiCH1bPpQvIlEvhlZYXXhzJ45YVL3Eqt2 FA7vqplFXhN3LTTWzmnT242TybdVjIFgiJpw4PKW4EiiHqtjcQg4qk8WA1uY6jAgxI G1nRhqfRKB9km2m5D0T8fMT66CghJCx0/7AUoZcO8UCOAevRogOTzowPLUWt88D+Mn fpQXykuxmu/urDsK+WMnruw6yDcnngEJzwrfD/n1A9mIwwgoVt7cjyM97OJCyFonoX 4wqHSaPcLNyYbYZc2GIni7IeHVdFUY2llDZvIiScktcsq3dnkqDsou01DYSHyR1L8a 6rwLXYWYSJRLg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C3BD68072D; Sat, 16 Sep 2023 17:31:42 -0400 (EDT) Received: from pastel (unknown [104.247.237.102]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92B421201FC; Sat, 16 Sep 2023 17:31:42 -0400 (EDT) From: Stefan Monnier In-Reply-To: <87r0mxaowp.fsf@gmail.com> (Max Brieiev's message of "Sat, 16 Sep 2023 22:39:18 +0300") Message-ID: References: <87sfissyz3.fsf@web.de> <87v8cb9pns.fsf@gmail.com> <87r0mxaowp.fsf@gmail.com> Date: Sat, 16 Sep 2023 17:31:41 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.108 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Notice, that the above code does not visually appear to use any lambdas, > but it fails, because internally it expands to lambdas, causing > (void-function cps-internal-yield). > > Now, let's get back to the original problem - the fact that in "local > CPS" the "locality" of the lambda must be completely known. If we look > at `named-let` it appears to be completely self-contained: the control > flow and the usage of higher order functions that it expands to is fully > known due to the way it is encoded into the macro. For `named-let` we don't have such a guarantee. You can do: (named-let my-foo ((x 1) (y 2)) [...] (mapcar #'my-foo ...) [...] (set-process-filter proc #'my-foo) [...]) In most use cases, tho, we do, indeed. > So provided with this information, do we have enough information to > perform a CPS conversion of the `named-let`? Usually, there is enough info to do it locally, yes. [ We don't currently analyze enough of the code to have that information, OTOH. ] > Similarly, in pcase, unless the handler is provided as a lambda by the > user, the internal/expanded lambdas might be "local enough" to perform > CPS conversion. For `pcase`, yes, definitely (and indeed, we'd want to compile those lambdas into something more efficient). It's more: we know they're always called in a "tail call" position, so they can (in theory) be treated by the CPS as continuations rather than arbitrary functions. > What I am trying to say is that, if "local CPS conversion" of higher > order functions is impossible to perform in general, then could we > possibly make conversions on a macro per macro basis, when the macro is > "local enough"? Yes, that would be very welcome. The easiest might be to make `generator.el` operate on the code before macro-expansion (so it gets to see `pcase` and `named-let` and can dispatch to ad-hoc code like it does for special forms). Another option is to improve `generator.el` to the point where it can recognize the kind of code generated by macros like `pcase` and `named-let` loops and treat it correctly. Yet another option might be to arrange for macros like `named-let` and `pcase` to leave hints in their code that make it easier for `generator.el` to do its work. Stefan From unknown Sat Jun 14 05:31:15 2025 X-Loop: help-debbugs@gnu.org Subject: bug#59140: 29.0.50; iter-yield from lambda Resent-From: Max Brieiev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 17 Sep 2023 06:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Heerdegen Cc: 59140@debbugs.gnu.org, okamsn@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 59140-submit@debbugs.gnu.org id=B59140.169493236924005 (code B ref 59140); Sun, 17 Sep 2023 06:33:02 +0000 Received: (at 59140) by debbugs.gnu.org; 17 Sep 2023 06:32:49 +0000 Received: from localhost ([127.0.0.1]:48908 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhlKr-0006F7-Dy for submit@debbugs.gnu.org; Sun, 17 Sep 2023 02:32:49 -0400 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]:51394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qhlKp-0006Eu-Mo for 59140@debbugs.gnu.org; Sun, 17 Sep 2023 02:32:48 -0400 Received: by mail-ej1-x62b.google.com with SMTP id a640c23a62f3a-9adca291f99so240881366b.2 for <59140@debbugs.gnu.org>; Sat, 16 Sep 2023 23:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694932354; x=1695537154; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=IteOC5kmU9jOGHtlvvTKY9WeHZ2LQtlRvFHIYrYAdLY=; b=D1InTY8kSH4w2ZsEZelpBWnUYuIxhnhUW9q+mOZ+j7FmxTAc4sN81ZfgHZOzTUckXA Y/G1ruABZ/TbfU4UOZyVobSosN0mZPloFIxvqBGtDTG4PAOKolmFpmnTNrprA8kaUVRi R4UbiC6L1BNkWTlfqDqwkG+pJH3szweofEwyNpqAz5of5NeqLW8i2fJVTyURgaOKXlec dUVEo7JZPQXJu7dDUa05hGut8LYUJv5SztZKCUgQfBD5pd38IsIyU5rhLgtbjNEAr4Rd 8B8gzbyF5aXt+D4GmVH3Bj6h2byGtmElAKJPx0W2hlf/y5cR++t9AsShd23hiSPArgFj ubwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694932354; x=1695537154; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IteOC5kmU9jOGHtlvvTKY9WeHZ2LQtlRvFHIYrYAdLY=; b=G5Gt6Gk3qIhYxprplcUq1kAhn6QFaXP1x1iTMU36bNRYVunHqkFVgMNe/CpCvnltUT 2Cljn6JAJ5bqiXvaJXvUrIEXU6BsSb4q0UF7rQH/3FMuIYmczks9GHiJdCCAtIHHhttX QCcGYV+/iX4tUQWpBC8sHuXcjceRH2SRTFSQCM610cE8/51mh0qSTFiii4nN1vJ1SORu mJAnLm3WQFRIUEgcvtdhxV0MrRM+IqPS+v2h9cRbUtC90NGEsx+yg4Wts33v+fOhV0rq 99GevzVcVZgBYK6FUD30BNmM7GqDTYyo8T+iiIt0OXlCTNf9paK+/zRgFwnckoV35RvI Nb8A== X-Gm-Message-State: AOJu0Yx+26hbuKVziHrHLsBagnvNFEdqdEjdSIyFWnN9qWpmDp0kwcbS IwLKzUY1IKVB/7crdLGPm1PQO4ltxjw= X-Google-Smtp-Source: AGHT+IHgQsrPJHF67JEx1XKFXe/B5teLlN8/W5ikjAOV82SteKkTkGZTsa9puYdH6/zYbqZ3Bfi1gw== X-Received: by 2002:a17:906:73cc:b0:9a5:da6c:6551 with SMTP id n12-20020a17090673cc00b009a5da6c6551mr5539321ejl.62.1694932354232; Sat, 16 Sep 2023 23:32:34 -0700 (PDT) Received: from vmax ([109.251.233.9]) by smtp.gmail.com with ESMTPSA id lj23-20020a170906f9d700b009930c80b87csm4663123ejb.142.2023.09.16.23.32.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 16 Sep 2023 23:32:33 -0700 (PDT) From: Max Brieiev In-Reply-To: <87cyyianjg.fsf@web.de> (Michael Heerdegen's message of "Sat, 16 Sep 2023 03:56:35 +0200") References: <87sfissyz3.fsf@web.de> <87v8cb9pns.fsf@gmail.com> <87cyyianjg.fsf@web.de> Date: Sun, 17 Sep 2023 09:32:31 +0300 Message-ID: <87jzsp9uo0.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Michael Heerdegen writes: > Max Brieiev writes: > >> For example, this: >> >> (iter-defun my-generator () >> (funcall (lambda () (iter-yield 5)))) >> >> would be expanded by iter-defun macro into this: >> >> (... >> (let ((gen (iter-lambda () (iter-yield 5)))) >> (iter-next (funcall gen)))) >> >> Does it make sense? > > Does it? Isn't the `let' expression equivalent to just `5'? With other > words: you don't yield from an outside generator, as far as I > understand (or am I wrong? what's the content of your "..."?). > > Michael. You are right, the code is wrong, it should probably return a generator instead. What I attempted to show is how lambda would be turned into `iter-lambda`, conceptually. "..." is some expansion performed by `iter-defun`. In my intuition, if `iter-yield` is encountered inside a lambda, then it would be converted into generator, and then advance the created generator to the first yield expression, such that the following `iter-next` would resume execution from the suspnension point. But I might be wrong, the topic of generators is new to me, and I need to study it.