emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: Bruno Barbier <brubar.cs@gmail.com>,
	emacs-orgmode@gnu.org, Bastien <bzg@gnu.org>
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)
Date: Sat, 11 Mar 2023 18:30:31 +0000	[thread overview]
Message-ID: <d6988c6d-1484-be17-fc8c-cecabcc36e95@posteo.de> (raw)
In-Reply-To: <878rg3y5he.fsf@localhost>

On 3/11/23 10:58, Ihor Radchenko wrote:
> Zelphir Kaltstahl <zelphirkaltstahl@posteo.de> writes:
>> 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.
> I see.
> AFAIK, Elisp does not have this problem.
>> As far as I know, (defun ...) and (defvar ...) are merely defining functions and
>> variables, not macros.
> Same for defmacro in Elisp.
>> 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.
> When saying Guile I mean scheme. Remember that I am now looking from a
> more general perspective of other ob-* libraries.
> My conclusion so far is that it is not safe in ob-scheme to use
> let-binding. Other ob-* lisp implementations may be OK (at least,
> ob-emacs-lisp is OK).
> Now, the main question is whether it is safe to use `define' in all the
> scheme implementations. If it is, would you be interested in turning
> your personal fix into a patch for ob-scheme?

Sure! Would need to familiarize myself with with process of doing that, but why not.

I guess it would be a safer bet to await, whether the patch is what the general 
solution should be. Or would a patch be good to have, regardless of whether the 
official implementation changes or not, so that others can apply it perhaps, 
instead of putting something in their personal init file?

repositories: https://notabug.org/ZelphirKaltstahl

  reply	other threads:[~2023-03-11 18:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 11:27 org-babel guile source block bug in handling multiple values Zelphir Kaltstahl
2023-03-07 14:36 ` Ihor Radchenko
2023-03-07 15:18   ` Zelphir Kaltstahl
2023-03-07 19:52     ` Bruno Barbier
2023-03-08  0:55       ` Zelphir Kaltstahl
2023-03-08 19:38         ` Bruno Barbier
2023-03-09  0:44           ` Zelphir Kaltstahl
2023-03-09 13:04             ` [BUG] Inconsistent global/local :var assignments in ob-* for lisps and non-lisps (was: org-babel guile source block bug in handling multiple values) Ihor Radchenko
2023-03-10 10:39               ` Zelphir Kaltstahl
2023-03-11  9:58                 ` Ihor Radchenko
2023-03-11 18:30                   ` Zelphir Kaltstahl [this message]
2023-03-12 11:33                     ` Ihor Radchenko
2023-03-19 13:50                   ` [PATCH] lisp/ob-scheme.el Zelphir Kaltstahl
2023-03-22 10:43                     ` Ihor Radchenko
2023-03-25 14:34                       ` Zelphir Kaltstahl
2023-03-26  9:32                         ` Ihor Radchenko
2023-04-25 12:28                         ` Ihor Radchenko
2023-04-29 11:08                           ` Zelphir Kaltstahl
2023-03-09 13:10             ` org-babel guile source block bug in handling multiple values Ihor Radchenko
2023-03-10 10:42               ` Zelphir Kaltstahl
2023-03-11 10:18                 ` Ihor Radchenko
2023-06-02 13:11                   ` Ihor Radchenko
2023-03-09 13:11             ` Ihor Radchenko
2023-03-09 14:21               ` Daniel Kraus
2023-03-10 11:57                 ` Ihor Radchenko
2023-03-10 10:45               ` Zelphir Kaltstahl
2023-03-08  1:13       ` Zelphir Kaltstahl
2023-03-08  8:55         ` Ihor Radchenko
2023-03-07 15:44 ` Max Nikulin
2023-03-07 21:41 ` Rudolf Adamkovič

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6988c6d-1484-be17-fc8c-cecabcc36e95@posteo.de \
    --to=zelphirkaltstahl@posteo.de \
    --cc=brubar.cs@gmail.com \
    --cc=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).