From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id UEpKOf7iB2Q7jQAASxT56A (envelope-from ) for ; Wed, 08 Mar 2023 02:21:03 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id kOMMOf7iB2SVNQEAauVa8A (envelope-from ) for ; Wed, 08 Mar 2023 02:21:02 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 64F28384BA for ; Wed, 8 Mar 2023 02:21:02 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pZiNP-0002VZ-Ih; Tue, 07 Mar 2023 20:13:55 -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 1pZiNN-0002HM-7i for emacs-orgmode@gnu.org; Tue, 07 Mar 2023 20:13:53 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pZiNK-0001yR-3K for emacs-orgmode@gnu.org; Tue, 07 Mar 2023 20:13:52 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id B3FD02406E5 for ; Wed, 8 Mar 2023 02:13:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1678238027; bh=/OXx1+Khn7rjBfKGzocffVxV1uj5e/rqOaEZnteC7dA=; h=Date:Subject:To:Cc:From:From; b=kY5vCLthhZLEZkN+T+5OUxImKD/AFaiDMcAyXZn4f1XZ6eP7Uv1YgyqkZBg5A0PYg Q0IprZ5eHjZ4sZXM7z7Tbm0pUxQvO8z9cGB/dQZtgSMDRpl/xAhcy0hEpIl6LmBAmT m+yBqvei4YgP8KAoMwD+EA1APnQ/S0F0dYgdCVfP7HOFcXrRiNEisUPpFRF/mDZ663 UzTiOlJ0F/zWK+tXvDRgAb5JwE75OCXkl3BQusK42xZU4Wftgw7a9v4NE5wICiu3T2 7gdMgWbu+RjH6FtU4r3VNXmglAtrYfVchPgQblB1g5b89YpyWN3BTxKunR+LtkWGoC AZUIBxYn8xs6Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PWZ8B5TSNz9rxN; Wed, 8 Mar 2023 02:13:46 +0100 (CET) Content-Type: multipart/alternative; boundary="------------oK2td0iK220mTaBZvbsz0kl0" Message-ID: Date: Wed, 8 Mar 2023 01:13:45 +0000 MIME-Version: 1.0 Subject: Re: org-babel guile source block bug in handling multiple values Content-Language: en-US To: Bruno Barbier Cc: emacs-orgmode@gnu.org, Ihor Radchenko References: <9eab60bc-9b82-e037-d63b-3d879573ae32@posteo.de> <87v8jceihi.fsf@localhost> <7fc63848-d6d3-80e0-ae78-00967990813d@posteo.de> <64079614.170a0220.5a0d3.0a23@mx.google.com> From: Zelphir Kaltstahl In-Reply-To: <64079614.170a0220.5a0d3.0a23@mx.google.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=zelphirkaltstahl@posteo.de; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678238462; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=tQoDLMp9mL5V3K51GC61XqUQhk0kDAx2uEz7i2l9Qv8=; b=c5nd7XY4B90VgWPU6bK1XQmECoxZKMguQnB/PKZ/NUQjLLmNVIZbK8ZSD+SX7CsOvVOmgh wLwXlqNVoZTeJx/kXYORD+3uHSfeCtz5NmvaS+sjvzrio9j1dRzk7cmJWgj8A3ZCV/IbJV WZ1HtA1GKKxK6t0N7xjoll6avXq3Tdf/qwMQfOQUmdXL38Hv7JwISyn3CTVehDknrsiZSq 8iuYViAuemfW/n68f2k+36XboZGTNyiNNVDcd88Q8DDnAy3gMJefwtbq1xu+LsdbijiDxg s9xwg+AmihhXtdLAeyQy/fBiiAAdcYog594Y22DYMuwFdVYQFhfiy6V4pHsRog== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=kY5vCLth; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.de ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678238462; a=rsa-sha256; cv=none; b=P/+gMSog8D4AnJl4ij/EpGO0ditVbWJrACPe+lhI1ubyHJp7XNDyo7uRFSDIga6muGHK5C pX3psZWs8iQleWfdSf8So6CcGyu4tXdNAcqx+PSTycaE0GVwW8x8RxOLcudg/9OinZAO7A gH/1DXBKTlduizlGKbqISBevpitH/hzN78IkxK6uyam6c0u4Jz/lsNPCDZXowLsvtGJOEd D6SUZWwBZQBOGhl6+zvrazuG/yJiTKNSnoOCqnnDHr33VDIj7Hzwnv1aE+TXvqw4wMtNV7 8tZBNn72xsBth/XFEDThCmrnGDFcZgHfCll5tOIHJ2M624149GVkqtLVVkQVqA== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=kY5vCLth; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=none) header.from=posteo.de X-Migadu-Spam-Score: -6.28 X-Spam-Score: -6.28 X-Migadu-Queue-Id: 64F28384BA X-Migadu-Scanner: scn1.migadu.com X-TUID: iT6og0pJTJk4 This is a multi-part message in MIME format. --------------oK2td0iK220mTaBZvbsz0kl0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 3/7/23 20:52, Bruno Barbier wrote: > Zelphir Kaltstahl writes: > > >> If org merely wraps in a `let`, it should not notice any of the multiple values >> business, because that is something done internally in `let-values`. >> > The "let", to define the org variables, ends up putting the "import" > inside the scheme expression, like this: > > ;; -*- geiser-scheme-implementation: guile -*- > (let ((x '1) > (y '2)) > (import (except (rnrs base) error vector-map) > (only (guile) > lambda* > λ) > ;; let-values > (srfi srfi-11)) > > (let-values ([(a b) (values x y)]) > (simple-format #t "~a ~a\n" a b)) > ) > > > which raises an error when evaluated the first time (the second time, > the "import" has already imported the new "let-values" feature > (srfi-11), so, the evaluation works). You can test this manually in a > guile session. > > I guess you'll have to use sessions, and do the "import" in a separate > block first. > > Bruno Actually, now that I think about it, the whole problem is gone, when replacing the wrapping let with 2 separate (define ...), which I originally thought org would do: ~~~~START~~~~ $ guile GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (define x 1) scheme@(guile-user)> (define y 2) scheme@(guile-user)> (import (except (rnrs base) error vector-map) ... (only (guile) ... lambda* ... λ) ... ;; let-values ... (srfi srfi-11)) scheme@(guile-user)> (let-values ([(a b) (values x y)]) ... (simple-format #t "~a ~a\n" a b)) 1 2 ~~~~~END~~~~~ Or in one input to the REPL: ~~~~START~~~~ $ guile GNU Guile 3.0.9 Copyright (C) 1995-2023 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. Enter `,help' for help. scheme@(guile-user)> (define x 1) scheme@(guile-user)> (define y 2) scheme@(guile-user)> (import (except (rnrs base) error vector-map) ... (only (guile) ... lambda* ... λ) ... ;; let-values ... (srfi srfi-11)) scheme@(guile-user)> (let-values ([(a b) (values x y)]) ... (simple-format #t "~a ~a\n" a b)) 1 2 ~~~~~END~~~~~ Is there a reason it has to be wrapped in a let, instead of simply define-ing the variables? Regards, Zelphir -- repositories:https://notabug.org/ZelphirKaltstahl --------------oK2td0iK220mTaBZvbsz0kl0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 3/7/23 20:52, Bruno Barbier wrote:
Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:



If org merely wraps in a `let`, it should not notice any of the multiple values 
business, because that is something done internally in `let-values`.


The "let", to define the org variables, ends up putting the "import"
inside the scheme expression, like this:

      ;; -*- geiser-scheme-implementation: guile -*-
      (let ((x '1)
            (y '2))
      (import (except (rnrs base) error vector-map)
               (only (guile)
                     lambda*
                     λ)
               ;; let-values
               (srfi srfi-11))

      (let-values ([(a b) (values x y)])
         (simple-format #t "~a ~a\n" a b))
      )


which raises an error when evaluated the first time (the second time,
the "import" has already imported the new "let-values" feature
(srfi-11), so, the evaluation works). You can test this manually in a
guile session.

I guess you'll have to use sessions, and do the "import" in a separate
block first.

Bruno

Actually, now that I think about it, the whole problem is gone, when replacing the wrapping let with 2 separate (define ...), which I originally thought org would do:

~~~~START~~~~
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define x 1)
scheme@(guile-user)> (define y 2)
scheme@(guile-user)> (import (except (rnrs base) error vector-map)
...         (only (guile)
...               lambda*
...               λ)
...         ;; let-values
...         (srfi srfi-11))
scheme@(guile-user)> (let-values ([(a b) (values x y)])
...   (simple-format #t "~a ~a\n" a b))
1 2
~~~~~END~~~~~

Or in one input to the REPL:

~~~~START~~~~
$ guile
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (define x 1)
scheme@(guile-user)> (define y 2)
scheme@(guile-user)> (import (except (rnrs base) error vector-map)
...         (only (guile)
...               lambda*
...               λ)
...         ;; let-values
...         (srfi srfi-11))
scheme@(guile-user)> (let-values ([(a b) (values x y)])
...   (simple-format #t "~a ~a\n" a b))
1 2
~~~~~END~~~~~

Is there a reason it has to be wrapped in a let, instead of simply define-ing the variables?

Regards,
Zelphir

-- 
repositories: https://notabug.org/ZelphirKaltstahl
--------------oK2td0iK220mTaBZvbsz0kl0--