Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Ihor Radchenko  writes:

> Zelphir Kaltstahl  writes:
>
>>> This is expected. Noweb includes the src block code without altering it.
>>> See 16.11 Noweb Reference Syntax
>>>
>>> We may probably clarify this in the manual. Would it be helpful?
>> I think it would be helpful. I merely tried Python, because it was at hand 
>> and 
>> because I did not find ob-racket in M-x package-list RET and did not have 
>> another Scheme installed. Cannot say, whether others find the behavior 
>> confusing 
>> or not, but I imagine I would find it helpful, if it was mentioned in the 
>> docs.
>
> See the attached tentative patch.

Applied, with amendments. I moved the example to a footnote. Otherwise,
the section flow does not read right.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dbb451dc9

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

>> This is expected. Noweb includes the src block code without altering it.
>> See 16.11 Noweb Reference Syntax
>>
>> We may probably clarify this in the manual. Would it be helpful?
> I think it would be helpful. I merely tried Python, because it was at hand 
> and 
> because I did not find ob-racket in M-x package-list RET and did not have 
> another Scheme installed. Cannot say, whether others find the behavior 
> confusing 
> or not, but I imagine I would find it helpful, if it was mentioned in the 
> docs.

See the attached tentative patch.

>From 26763df7de8f742e76f10f2e7603ed290b97df65 Mon Sep 17 00:00:00 2001
Message-Id: <26763df7de8f742e76f10f2e7603ed290b97df65.1678529850.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sat, 11 Mar 2023 11:16:23 +0100
Subject: [PATCH] org-manual.org: Explain that noweb expansion does not carry
 over :var

* doc/org-manual.org (Noweb Reference Syntax): Provide an example
explaining that :var header arguments are not in effect when expanding
noweb reference.

Reported-by: Zelphir Kaltstahl 
Link: https://orgmode.org/list/46e6f579-9eca-e1da-06ea-f2478a603...@posteo.de
---
 doc/org-manual.org | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 1c97d6aa8..2c3ec46a4 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -19117,6 +19117,32 @@ ** Noweb Reference Syntax
 ,#+END_SRC
 #+end_example
 
+Note that noweb expansion does not automatically carry over =var=
+header arguments.  In the following example, attempting to evaluate
+the second code block will give an error, because the variables
+defined in the first code block will not be defined in the second
+block.
+
+#+begin_example
+,#+NAME: get-prompt
+,#+BEGIN_SRC emacs-lisp :var prompt="root> " :var command="ls"
+  (concat prompt command)
+,#+END_SRC
+
+,#+RESULTS: get-prompt
+: root> ls
+
+,#+BEGIN_SRC emacs-lisp :noweb yes
+  <>
+,#+END_SRC
+
+The previous block is expanded to
+
+,#+BEGIN_SRC emacs-lisp
+  (concat prompt command)
+,#+END_SRC
+#+end_example
+
 You may also include the contents of multiple blocks sharing a common
 =noweb-ref= header argument, which can be set at the file, subtree,
 or code block level.  In the example Org file shown next, the body of
-- 
2.39.1


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Daniel Kraus  writes:

> If I could freely choose if a :var declaration in one source block
> should create a global variable for all other blocks in this session,
> I would say making it only available in the defining source block
> is more natural (i.e. use let instead of def).

You can always introduce a language-specific header argument that will
control this behaviour. If you think that it can be useful.

Note that org-babel gives no promises about :vars being globally
available in :session. So, there is technically no obligation to prefer
global definition over let-binding. Unless let-binding can cause bugs,
as the one reported here for Guile.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/9/23 14:11, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


OK, to wrap up (ha!), I want to ask:

(q1) What is a rationale, if any, behind the let-wrapping?

It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel, the maintainer of ob-clojure (we have no active
maintainer for ob-scheme now). Maybe, Daniel has some useful insight.


(q2) Any chances of that changing to (define ...)?

This sounds reasonable.


(q3) How could I change my org-mode's code to not  let-wrap, and instead use
(define ...)?

See `org-babel-expand-body:scheme'. You can re-define it for a quick
temporary fix.


Thanks for the hint!

Here is my fix for my init.el:

START
;; Redefine/override org-babel-expand-body:scheme to avoid
;; let-wrapping with :var header args in source blocks.

(defun xiaolong/org-babel-format-vars (vars)
  "Format :var header arguments given as VARS."
  (mapconcat (lambda (var)
   (format "(define %s %S)" (car var) (cdr var)))
 vars
 "\n"))

(eval-after-load "org"
  '(defun org-babel-expand-body:scheme (body params)
 "Expand BODY according to PARAMS, return the expanded body."
 (let ((vars (org-babel--get-vars params))
   (prepends (cdr (assq :prologue params)))
   (postpends (cdr (assq :epilogue params
   (concat (and prepends (concat prepends "\n"))
   (if (null vars)
   body
 (concat (xiaolong/org-babel-format-vars vars) body))
   (and postpends (concat "\n" postpends))
~END~

That was simpler than I expected and the first time I overrode anything of 
org-mode =)


Regards,
Zelphir

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

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/9/23 14:10, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


START
#+name: python-imports
#+begin_src python :python /usr/bin/python3 :results output replace drawer :var 
x=4
import math

y = math.sqrt(x)
# print(y)
#+end_src

#+name: python-usage
#+begin_src python :python /usr/bin/python3 :return :noweb strip-export 
:results value replace drawer
<>

print("y: {}".format(y))
#+end_src
~END~

Unfortunately, this example does not seem to work at all, but for a different
reason:

It seems that using any Python source block with :var header args via :noweb
does not work, as it then behaves in the way, that it merely pasted the included
source block, without first putting in the :var values into the variables. I get
errors about those :var variables being undefined, of course, since they are on
the included source block, not on the including one:

START: *Org-Babel Error Output*
Traceback (most recent call last):
File "", line 10, in 
File "", line 5, in main
NameError: name 'x' is not defined
[ Babel evaluation exited with code 1 ]
~END~

This is expected. Noweb includes the src block code without altering it.
See 16.11 Noweb Reference Syntax

We may probably clarify this in the manual. Would it be helpful?
I think it would be helpful. I merely tried Python, because it was at hand and 
because I did not find ob-racket in M-x package-list RET and did not have 
another Scheme installed. Cannot say, whether others find the behavior confusing 
or not, but I imagine I would find it helpful, if it was mentioned in the docs.


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

Re: org-babel guile source block bug in handling multiple values

[Daniel Kraus]

Ihor Radchenko  writes:

> Zelphir Kaltstahl  writes:

>> (q1) What is a rationale, if any, behind the let-wrapping?
>
> It makes sense in ob-emacs-lisp to not litter global Emacs state.
> In other ob-* lisp backends, I am not sure.
> I am CCing Daniel, the maintainer of ob-clojure (we have no active
> maintainer for ob-scheme now). Maybe, Daniel has some useful insight.

No, unfortunately I don't have any more insights than already discussed.

I think wrapping the vars in let just seems natural for lisps.

If I could freely choose if a :var declaration in one source block
should create a global variable for all other blocks in this session,
I would say making it only available in the defining source block
is more natural (i.e. use let instead of def).
But given that apparently almost all other babel languages define
a global var, I'll just make the same change in ob-clojure?!

Cheers,
  Daniel

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> OK, to wrap up (ha!), I want to ask:
>
> (q1) What is a rationale, if any, behind the let-wrapping?

It makes sense in ob-emacs-lisp to not litter global Emacs state.
In other ob-* lisp backends, I am not sure.
I am CCing Daniel, the maintainer of ob-clojure (we have no active
maintainer for ob-scheme now). Maybe, Daniel has some useful insight.

> (q2) Any chances of that changing to (define ...)?

This sounds reasonable.

> (q3) How could I change my org-mode's code to not  let-wrap, and instead use 
> (define ...)?

See `org-babel-expand-body:scheme'. You can re-define it for a quick
temporary fix.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> START
> #+name: python-imports
> #+begin_src python :python /usr/bin/python3 :results output replace drawer 
> :var x=4
> import math
>
> y = math.sqrt(x)
> # print(y)
> #+end_src
>
> #+name: python-usage
> #+begin_src python :python /usr/bin/python3 :return :noweb strip-export 
> :results value replace drawer
> <>
>
> print("y: {}".format(y))
> #+end_src
> ~END~
>
> Unfortunately, this example does not seem to work at all, but for a different 
> reason:
>
> It seems that using any Python source block with :var header args via :noweb 
> does not work, as it then behaves in the way, that it merely pasted the 
> included 
> source block, without first putting in the :var values into the variables. I 
> get 
> errors about those :var variables being undefined, of course, since they are 
> on 
> the included source block, not on the including one:
>
> START: *Org-Babel Error Output*
> Traceback (most recent call last):
>File "", line 10, in 
>File "", line 5, in main
> NameError: name 'x' is not defined
> [ Babel evaluation exited with code 1 ]
> ~END~

This is expected. Noweb includes the src block code without altering it.
See 16.11 Noweb Reference Syntax

We may probably clarify this in the manual. Would it be helpful?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/8/23 20:38, Bruno Barbier wrote:

Hi Zelphir,

Zelphir Kaltstahl  writes:


On 3/7/23 20:52, Bruno Barbier wrote:
Also thanks for the idea with sessions + separate import source block. I thought
that should work, but apparently that also has the same error, when running for
the first time:

...

Oh, I see. I tested something way simpler :-)

First, one block to open and configure the guile session.

  #+begin_src scheme :session "!guile" :results silent
  (import (except (rnrs base) error vector-map)
   (only (guile)
 lambda*
 λ)
   ;; let-values
   (srfi srfi-11))
  #+end_src

Then, you can get to work and evaluate as many blocks as you like in
that session:

  #+begin_src scheme :session "!guile" :results output replace drawer :var 
x=1 :var y=2
  (let-values ([(a b) (values x y)])
 (simple-format #t "~a ~a\n" a b))
  #+end_src

  #+RESULTS:
  :results:
  1 2
  :end:

Bruno

Hello Bruno and hello mailing list!

I just tested it a little more:

If there is any (import ...) at all in the code block that makes use of the 
(let-values ...), it seems to somehow disturb already imported libraries. For 
example the following also does not work:


START
#+name: scheme-time-imports
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer"
(import
 (except (rnrs base) error vector-map)
 (only (guile)
   lambda*
   λ)
 ;; let-values
 (srfi srfi-11))
#+end_src

#+RESULTS: scheme-time-imports

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer :var x=1 :var y=2
<>
(import (srfi srfi-1))
(let-values ([(a b) (values x y)])
   (simple-format #t "~a ~a\n" a b))
#+end_src
~END~

So that means, even if the import has nothing to do with the actual import which 
would provide the let-values form, it disturbs it.


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 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 ...).


What is still a bit weird about it is, that in the original example with 
`let-values` I don't get an error about `let-values` not being defined, but only 
about `a` not being defined. And in the example with (define ...) and :var 
above, I get a message about `x` not being defined, instead of `a` not being 
defined.


Probably a good general workaround is to only have imports at the top level, by 
moving them into a source block, which does not have any :var header arguments.


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 

Re: org-babel guile source block bug in handling multiple values

[Bruno Barbier]

Hi Zelphir,

Zelphir Kaltstahl  writes:

> On 3/7/23 20:52, Bruno Barbier wrote:

> Also thanks for the idea with sessions + separate import source block. I 
> thought 
> that should work, but apparently that also has the same error, when running 
> for 
> the first time:
>
> ...

Oh, I see. I tested something way simpler :-)

First, one block to open and configure the guile session.

 #+begin_src scheme :session "!guile" :results silent
 (import (except (rnrs base) error vector-map)
  (only (guile)
lambda*
λ)
  ;; let-values
  (srfi srfi-11))
 #+end_src

Then, you can get to work and evaluate as many blocks as you like in
that session:

 #+begin_src scheme :session "!guile" :results output replace drawer :var 
x=1 :var y=2
 (let-values ([(a b) (values x y)])
(simple-format #t "~a ~a\n" a b))
 #+end_src

 #+RESULTS:
 :results:
 1 2
 :end:

Bruno

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> 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:
> ...
> Is there a reason it has to be wrapped in a let, instead of simply define-ing 
> the variables?

Because (define ...) will, AFAIU, define the variables in the whole
session, including subsequent code block calls. Let-binding is safer in
this regard - it only affects a specific code block.

For the problem of (import ...), a similar problem is solved by ob-C
using :includes header argument. See
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-C.html

I am not yet sure if let-binding around (import ...) must never be done
in Guile. It would be helpful of someone more familiar with Guile chimes
in.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

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

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

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


Hello Bruno!

Thank you for that explanation. Behaves exactly like you describe and explains 
things.


I wonder though, whether that let wrapped code should actually cause an error, 
or that is a bug in Guile.


Also thanks for the idea with sessions + separate import source block. I thought 
that should work, but apparently that also has the same error, when running for 
the first time:


START
#+name: scheme-time-imports
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer"
(import
 ;; let-values
 (srfi srfi-11))
#+end_src

#+RESULTS: scheme-time-imports

#+name: scheme-time
#+begin_src scheme :eval query-export :noweb strip-export :session scheme-time 
:results output replace drawer :var x=1 :var 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))
#+end_src

#+RESULTS: scheme-time
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:
~END~

Regards,
Zelphir

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

Re: org-babel guile source block bug in handling multiple values

[Rudolf Adamkovič]

Zelphir Kaltstahl  writes:

> There seems to be an issue with returning multiple values,

By the way, (Common) Lisp also has problems with multiple values in Org, as I
have recently learned in a discussion with the author of SLY (the modern
alternative to SLIME), João Távora.  He says:

> But this is wrong anyway, because in good Lisp REPL tradition, it should
> return the string braced with quotes, so it is READ able, and this doesn't
> work for multiple values anyway.
> 
> #+begin_src lisp
> (values 1 2 3)
> #+end_src
> 
> #+RESULTS:
> : 1

See (at the bottom of):

https://github.com/joaotavora/sly/issues/334

Rudy
-- 
"Chop your own wood and it will warm you twice."
-- Henry Ford; Francis Kinloch, 1819; Henry David Thoreau, 1854

Rudolf Adamkovič  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: org-babel guile source block bug in handling multiple values

[Bruno Barbier]

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

Re: org-babel guile source block bug in handling multiple values

[Max Nikulin]

On 07/03/2023 18:27, Zelphir Kaltstahl wrote:

because somehow there is no ob-racket and I think I would need that.


See the following thread for a couple of links. Disclaimer: I have never 
used racket, so I do not know real state of affairs.


https://list.orgmode.org/ca+pajwlyuzvka3gfshgxzeqhofwivg-fdhe4bpf7z6fqwva...@mail.gmail.com/T/#u
Updates to ob-racket mode, code review request
2020-07-09 15:03 George Mauer

Re: org-babel guile source block bug in handling multiple values

[Zelphir Kaltstahl]

On 3/7/23 15:36, Ihor Radchenko wrote:

Zelphir Kaltstahl  writes:


* Multiple values involving =:var= variables

#+begin_src scheme :eval query-export :results output replace drawer :var x=1 
:var 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))
#+end_src

#+RESULTS:
:results:
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>
:end:

I am not familiar with scheme, but AFAIK all ob-scheme does is wrapping
the code block into (let (...) ,@body) See `org-babel-expand-body:scheme'.

May the problem be with your let-values form?


The problem seems to be associated with returning multiple values, which 
`let-values` is designed to capture. The expression `(values ...)` returns 2 
values and the `(let ([(a b) ]) )` will capture 
those 2 values, binding them to `a` and `b`. The `(let-values ...)` then creates 
a value (or in other scenarios any number of values) in its `` part as a 
result of the whole `let-values` expression. In my case the body performs a 
side-effect of printing something out, which is required to get something as an 
output of the source block.


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`.


I can run the code in geiser manually without error, but when I run it as a 
source block, I get the error as seen in the example org document of my original 
e-mail.


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

Re: org-babel guile source block bug in handling multiple values

[Ihor Radchenko]

Zelphir Kaltstahl  writes:

> * Multiple values involving =:var= variables
>
> #+begin_src scheme :eval query-export :results output replace drawer :var x=1 
> :var 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))
> #+end_src
>
> #+RESULTS:
> :results:
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Unbound variable: a
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]>
> :end:

I am not familiar with scheme, but AFAIK all ob-scheme does is wrapping
the code block into (let (...) ,@body) See `org-babel-expand-body:scheme'.

May the problem be with your let-values form? 

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at