From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 29 06:49:12 2021 Received: (at submit) by debbugs.gnu.org; 29 Apr 2021 10:49:12 +0000 Received: from localhost ([127.0.0.1]:54928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc4EK-0000Qg-CU for submit@debbugs.gnu.org; Thu, 29 Apr 2021 06:49:12 -0400 Received: from lists.gnu.org ([209.51.188.17]:39432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lc4EI-0000QZ-WC for submit@debbugs.gnu.org; Thu, 29 Apr 2021 06:49:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lc4EI-0005Dm-OS for bug-guile@gnu.org; Thu, 29 Apr 2021 06:49:10 -0400 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]:42515) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lc4EH-0006Zg-2f for bug-guile@gnu.org; Thu, 29 Apr 2021 06:49:10 -0400 Received: by mail-pg1-x531.google.com with SMTP id m12so6104898pgr.9 for ; Thu, 29 Apr 2021 03:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FvJcHJ4F4Oipt1WXbQsqjzlFouIgPYSvqrvyYg5uLks=; b=Gsmr2WFnBKmO+tRQkpxWSw36C/kQ2FZ2z0GNot/G1HG4Ion3vWXcsJfGV/ZCZYhPrT xrXLcDGM9tT5kBQK+t5BCyQtQyljdDvn/8BXLhDFSI/Lem5gOfIU9pIXIZr4/FUA9TMf g7CElc6qaFJPfJxj+seYm+YfR7dqtnhCNDIC4se3+cnhQDB8e1Rrsi4fzhNOmzXdM3Zr si9y6MNJzy4zArngu+nYIu11qraNylfn8wvtIMgBa23MvHgbRO2pr8GwrlpjhukT9Ev6 Xz0V2nxYG5CqOvVlX6HDYNshuspwsa5CP6zZHfBnODQbLPafMRmeStwoR4cFRzZ+J1dy 2c+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FvJcHJ4F4Oipt1WXbQsqjzlFouIgPYSvqrvyYg5uLks=; b=euIwo5XbOZf7o7CI3I7Ylh/cBscdIn93BvFfoCxNXJ4KPRTg9SYaxOIsWJTHcLJbXD nF8c04dOR7gXs4BW92X3qH2SyA1KUAO/anhhb9SY1ublr4pyd7SMz5NCsVSKrCxVlpw0 Ft/xN0SyKTIvZw8xhuqxTBa97g+X4yUs5E5X4PvuOAGtmvRN9+J8vU0u+YYFZWpVtrhG n3fLePW2mF619aGgZoj/6ccQABV5OTI4IbrKdq8Pno6pCjQgXNSzcY9sjDSf0fER9Oj4 koFg0Ai3D0QIMBa4pfAiZ7nwwqRyBoJCN//wJNz+lFZ/XECvy8eYq9Fhokmb43Qxk9FS etcA== X-Gm-Message-State: AOAM533ffk3JUBG18MpcuD1ZYsMAdF+kp9qUBLhNANu+hiItaBdjZKKH JHCEhKMuFkaBaIES5KmEK96pQdbKppX7E9liGbRjeyetp2E= X-Google-Smtp-Source: ABdhPJzwqLVzu3M6fdDGwTxQ7Z76VR3+zagcGv+3ji6Zr0Auy/KAYujR+ZlundcLxcl9c+sYqpGbISOHpGVOh7af1lA= X-Received: by 2002:aa7:9837:0:b029:264:b19e:acce with SMTP id q23-20020aa798370000b0290264b19eaccemr32460093pfl.79.1619693346600; Thu, 29 Apr 2021 03:49:06 -0700 (PDT) MIME-Version: 1.0 From: Stefan Israelsson Tampe Date: Thu, 29 Apr 2021 12:48:55 +0200 Message-ID: Subject: let/ec compilation bug To: bug-guile@gnu.org Content-Type: multipart/mixed; boundary="00000000000091dc0705c11a3ed5" Received-SPF: pass client-ip=2607:f8b0:4864:20::531; envelope-from=stefan.itampe@gmail.com; helo=mail-pg1-x531.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, HTML_MESSAGE=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.3 (-) X-Debbugs-Envelope-To: submit 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.3 (--) --00000000000091dc0705c11a3ed5 Content-Type: multipart/alternative; boundary="00000000000091dc0505c11a3ed3" --00000000000091dc0505c11a3ed3 Content-Type: text/plain; charset="UTF-8" Here is an interesting test case that shows that fi we define (define-syntax-rule (letec-m f) (let/ec c (f c))) (define (letec-f f) (let/ec c (f c))) we can get two different behaviors with letec-m compiles wrongly. Obviously a bug! This is important in casy you would like to make a loop macro effectively with a continue directive. --00000000000091dc0505c11a3ed3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is an interesting test case that shows that fi we def= ine
(define-syntax-rule (letec-m f) (let/ec c (f c)))
(define= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (lete= c-f f) (let/ec c (f c)))

we can get two differ= ent behaviors with letec-m compiles wrongly. Obviously=C2=A0a bug!

This is important in casy you would like to make a loop ma= cro effectively with a continue directive.
--00000000000091dc0505c11a3ed3-- --00000000000091dc0705c11a3ed5 Content-Type: text/x-scheme; charset="US-ASCII"; name="a.scm" Content-Disposition: attachment; filename="a.scm" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_ko2rl3ek0 KHVzZS1tb2R1bGVzIChpY2UtOSBjb250cm9sKSkKCihkZWZpbmUtc3ludGF4LXJ1bGUgKGxldGVj LW0gZikKICAobGV0L2VjIGMgKGYgYykpKQoKKGRlZmluZSAobGV0ZWMtZiBmKQogIChsZXQvZWMg YyAoZiBjKSkpCgoobGV0ZWMtbSAobGFtYmRhIChicmVhaykgKGxldCBscCAoKGkgMCkpICh3aGVu ICg8IGkgMikgKHBrIDEgaSkgKGxwICgrIGkgMSkpKSkpKQoobGV0ZWMtZiAobGFtYmRhIChicmVh aykgKGxldCBscCAoKGkgMCkpICh3aGVuICg8IGkgMikgKHBrIDIgaSkgKGxwICgrIGkgMSkpKSkp KQoKI3wKT1VUUFVUOgoKOzs7ICgyIDApCjs7OyAoMiAxKQp8Iwo= --00000000000091dc0705c11a3ed5-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 02 09:44:01 2021 Received: (at 48098-done) by debbugs.gnu.org; 2 May 2021 13:44:01 +0000 Received: from localhost ([127.0.0.1]:42888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldCO9-0003Eb-Fp for submit@debbugs.gnu.org; Sun, 02 May 2021 09:44:01 -0400 Received: from fanzine.igalia.com ([178.60.130.6]:32845) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldCO6-0003EV-UB for 48098-done@debbugs.gnu.org; Sun, 02 May 2021 09:44:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=JgqX+5hzMuygrw0y+PS55C8m1HlRF+362Rjir+EF8o4=; b=d9YstX6EUGS27qWD6JZ/XwtnfhyPbvYVjUcMy9JXUbJHsyLJQaEEL0Co/I+0w4WYH+ApfM6spFUjaLIyIAcYGoVQpIpz1yJJrGCxop1IujZQwoe7eHnXYZTdXBqdVlM7MY26bL8TLyNsdPW1jR36IFZJY4P+N76M1aqXh2NS2hvEfPsZHU2tNrM0jqaHmdx7rS8Yqvm2xNHxmvJOAr+ElQfa4QrBhLD0AN8BgXhVjnEClDsUByXuXj5GOqgQ+0RboA0izzq08p88QvQ1tvlCzDu8ih5AmaLBPkc8cCMFwjJbfVIUJA69kiCPEOz4YPdNrxstBI1pVBZf2wZauCwsIw==; Received: from 82-65-63-215.subs.proxad.net ([82.65.63.215] helo=sparrow) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim) id 1ldCO0-0000Ut-1w; Sun, 02 May 2021 15:43:52 +0200 From: Andy Wingo To: Stefan Israelsson Tampe Subject: Re: bug#48098: let/ec compilation bug References: Date: Sun, 02 May 2021 15:43:41 +0200 In-Reply-To: (Stefan Israelsson Tampe's message of "Thu, 29 Apr 2021 12:48:55 +0200") Message-ID: <87r1ipjlo2.fsf@igalia.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48098-done Cc: 48098-done@debbugs.gnu.org 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 (-) Thanks for the report; fixed! On Thu 29 Apr 2021 12:48, Stefan Israelsson Tampe writes: > Here is an interesting test case that shows that fi we define > (define-syntax-rule (letec-m f) (let/ec c (f c))) > (define (letec-f f) (let/ec c (f c))) > > we can get two different behaviors with letec-m compiles wrongly. Obviously a bug! > > This is important in casy you would like to make a loop macro effectively with a continue directive. From unknown Thu Jun 19 13:52:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 31 May 2021 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator