From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 SFZlJCcJC2T+ZQAASxT56A (envelope-from ) for ; Fri, 10 Mar 2023 11:40:39 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id sPdwIycJC2QiWAAAG6o9tA (envelope-from ) for ; Fri, 10 Mar 2023 11:40:39 +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 061A8226C5 for ; Fri, 10 Mar 2023 11:40:38 +0100 (CET) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=J9KyhF1J; 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-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1678444839; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=k6PfR1dhVub6dOBEui/aMWQGJ8HAcD8Uyk5SsnJX2e0=; b=tE4r38s4GLnEy01vbMxna8VhAZlNgSHdgqLriNX8v6uT9ceV70tREbbKvfj2N6bNiyQrxM I9S4HnM5j5tqQvxCu/w5ZU5PpWoL/h2TloHm+G8cYI0GqNmHj/X/7YOeCYONMu7dMpJ+8N FNMywScdn52LmNaLC5DeDa6mpa+KBdRj079wVfiOI7debS1HMKmCShnUuu93lDQDxCySHx QRS1aAIzJN5xFAmiMLA9NHWuD2INzKJN4mN5fP6TgCoHWB34Lg0bIeX1w5jmT5DhawiZ/U LAVkjrWfu3NBegBAq9+Gdm1fB6EtAy11i4xn9MAeyZ/D6FByEUrX9ef0n3dhOw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1678444839; a=rsa-sha256; cv=none; b=Ox+5JnWdG+xgV8ltC1s34ieC0kz5qGWIuLSsml+PKNii+HE0qSooOjm9xFxL4ska6MgTLF xUtwDLlHx74sZ0zZh3o6hWUzJwt3OOimPNAF2rVcny2OeTXgy8O6/JQn8ZobFuPlKR1o99 1HV1sE95Q0J3WIBB1AhHqr184I8QSK0HtTpZKCe5rj7h75iNUErq1xkwcshhxMC+mO+iVL XlSFjqYDtATiUq9RKa+CnX7rrORGX/MKEE1HJARqyIrJ/OeWyxHOiqly4dVU5ESFMEV3vn gP+wSwAkqOjkI/+fxY3FNcs7ngzSQXD94rZ3jtAujXnWNvxjuRzr+hjZZirS2A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.de header.s=2017 header.b=J9KyhF1J; 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 Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1paaAJ-0000rA-R0; Fri, 10 Mar 2023 05:39:59 -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 1paaAG-0000fi-0P for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 05:39:56 -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 1paaAD-0006HU-Tx for emacs-orgmode@gnu.org; Fri, 10 Mar 2023 05:39:55 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0903624045D for ; Fri, 10 Mar 2023 11:39:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1678444792; bh=mPxH0QBj7W2nAbeY9N0ayVfE6tYvxzBpKShcbAM4Fpw=; h=Date:Subject:To:Cc:From:From; b=J9KyhF1JWjwsAlAByZtm0KCcM0DU+294YnmkXmOI1tJcB6kOjjUrSlAbTdv789hpy g9bwPrF/xj4uLtA3esuu3dKRMqqdpxtnblAiWCj0XaYFzlX8iPJ/0410qL7E1ujblZ Tk7HbCHqXpCX2aBuG7XlKmJ3RAUbkO9iYL2PaythEJ0KTERdJEUevrk1eWATftZquD Ywqi9rwlaP4By701Bg4bvWWcFZgtdBAVBVbfnGJNN/T++At3s9GAchNWpXVi5ofxbF Wa1I4peztOz1AKPl9BgiV8bDqyIrKNqAIGH7E3ADOXupe9lHe4dTO7Yxb6MEGpDxhG uG+rmyGG52BcA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PY2cK719vz9rxD; Fri, 10 Mar 2023 11:39:45 +0100 (CET) Message-ID: <21ea836d-8bdf-2d0d-8515-283209f2eb1f@posteo.de> Date: Fri, 10 Mar 2023 10:39:45 +0000 MIME-Version: 1.0 Subject: Re: [BUG] Inconsistent global/local :var assignments in ob-* for lisps and non-lisps (was: org-babel guile source block bug in handling multiple values) To: Ihor Radchenko Cc: Bruno Barbier , emacs-orgmode@gnu.org, Bastien 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> <97ee254e-72d2-2bdf-e026-78bde076f1f9@posteo.de> <6408e424.5d0a0220.8862a.2a62@mx.google.com> <87v8jaoz3u.fsf@localhost> From: Zelphir Kaltstahl Content-Language: en-US In-Reply-To: <87v8jaoz3u.fsf@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: X-Migadu-Scanner: scn0.migadu.com X-Migadu-Queue-Id: 061A8226C5 X-Spam-Score: -9.07 X-Migadu-Spam-Score: -9.07 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-Flow: FLOW_IN X-Migadu-Country: US X-TUID: IqKj/fldPMaP On 3/9/23 14:04, Ihor Radchenko wrote: > Zelphir Kaltstahl writes: > >> I am not sure (let ...) is a correct wrapper for noweb included source blocks. >> What, if I write a (define ...) in my source block and want to use that source >> block via noweb in another source block? Expected behavior I think would be to >> be able to access those variables in other source blocks, since they are defined >> on a top level in an earlier source block, but if they are wrapped in a (let >> ...), that would make them only available in the (let ...)? It seems to me, that >> the simple wrapping with a (let ...) might not be the right thing to do. Testing >> that: >> >> ~~~~START~~~~ >> #+name: scheme-defs >> #+begin_src scheme :eval query-export :noweb strip-export :session myguile :results output replace drawer :var x=1 :var y=2 >> (define a x) >> (define b y) >> #+end_src >> >> #+name: scheme-time >> #+begin_src scheme :eval query-export :noweb strip-export :session myguile :results output replace drawer >> <> >> (simple-format #t "~a ~a\n" a b) >> #+end_src >> ~~~~~END~~~~~ >> >> Indeed, that also does not work. > I just checked ob-C, ob-shell, ob-emacs-lisp, and ob-clojure. > Non-lisps appear to assign the values globally. > In contrast, all the lisp babel backends are using let-bindings. > > Considering the existing inconsistency, and the raised bug I'd be in > favor of making variable assignments global in all the lisp babel > backends. > > The only possible exception is ob-emacs-lisp. Executing elisp code is > done in current Elisp session and thus using global variable assignments > may be tricky. Unless we juggle with multiple obarrays. > >> I guess I did never hit this problem earlier, because I "oursourced" my imports >> and in imports I do not need any :var header arguments. >> >> I've asked on the Guile IRC channel and something interesting is the case here >> (thanks for clearing it up flatwhatson!) and I understand it as follows: >> >> Imports inside (let ...) work. It is just that let-values is a macro and macros >> are expanded before execution time. However, Guile gets to the body of the >> wrapping (let ...) at execution time. That means, that when Guile gets to >> evaluate the body of the let, it does not expand the let-values, because it is >> already at execution time and no longer at macro expansion time. The import >> might import the let-values form, or might not, but it is already too late to >> expand the (let-values ...). > So, apparently using `let' is not universally safe in Guile. Is it safe in any Scheme? I think that depends on expansion and evaluation phases of the Scheme standards (see below). >> OK, the question is though, whether org should wrap anything in a (let ...) at >> all. During discussion on the Guile IRC, some points against let-wrapping were >> brought up: >> >> (1) The presence of a :var header argument currently determines, whether the >> code in the source block is wrapped with a (let ...). One argument for that was, >> that this way the variables do not leak. But this also decides, whether other >> things leak. For example (import ...) or (define ...). Should :var decide, >> whether bindings created with (define ...) are visible in other source blocks >> including the source block with the :var header arguments? It seems like a >> responsibility :var should not have and definitely is unexpected for the user. > This is something Guile-specific. In Elisp, let-binding still allows > `defun' or `defvar'. The issue is not with defining via (define ...) inside a (let ...) in Guile. It is about importing macros at the time, when the body of the (let ...) is already evaluated, which is at a later phase than macro expansion. By wrapping inside a (let ...) org has moved the import to a later phase, which causes the macro (let-values ...) to not be expanded. As far as I know, (defun ...) and (defvar ...) are merely defining functions and variables, not macros. My point is, that imports are usually global for sessions. But :var decided for let-wrapping, moving them to a different place. Just like imports are usually global, I would expect (define ...)s to be global in the session, unless I put them inside a narrowed scope like a (let ...) myself. The org generated (let ...) is invisible to the user and thus confusing, at least for GNU Guile. For other Schemes it probably all depends on how their phases of expansion and evaluation work. I don't know enough about the Scheme standards, to tell, whether Guile has the correct behavior here or whether there is a correct behavior defined in the Scheme standards. Maybe someone more knowledgeable can chime in to comment on that. -- repositories: https://notabug.org/ZelphirKaltstahl