Exporting a nonexistent variable

Exporting a nonexistent variable

[Tommi Höynälänmaa]

Exporting a nonexistent variable in a guile module can cause runtime 
errors. To see this, consider the following example:

--- mod1.scm ---

(define-module (mod1))

(export myproc)

(define (myproc)
   (display "Hello\n"))

--- end ---

--- mod2.scm ---
(define-module (mod2))

(export myproc
         myproc2)

(define (myproc2)
   (display "Hello again\n"))

--- end ---

--- program.scm ---
(use-modules (mod1)
              (mod2))

(define (main args)
   (myproc))

--- end ---

Running "guile -e main -s program.scm" causes the following error

---

WARNING: (guile-user): `myproc' imported from both (mod1) and (mod2)
Backtrace:
In ice-9/boot-9.scm:
   1762:12  4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
            3 (apply-smob/0 #<thunk 7f3e3cd10300>)
In ice-9/boot-9.scm:
     731:2  2 (call-with-prompt ("prompt") #<procedure 7f3e3cd22b00 …> …)
In ice-9/eval.scm:
     619:8  1 (_ #(#(#<directory (guile-user) 7f3e3cd13c80>)))
In program.scm:
       6:3  0 (main _)

program.scm:6:3: In procedure main:
Unbound variable: myproc

---

I think Guile could report a warning if a nonexistent variable is 
exported as the cause of this kind of errors may be difficult to find in 
a large program.

      - Tommi Höynälänmaa

-- 
Kotisivu / Homepage: http://www.iki.fi/tohoyn/
Sähköposti / E-Mail: tommi.hoynalanmaa@iki.fi
GPG-sormenjälki / GPG fingerprint:
55F4 2477 7155 3528 5CB2 2B7A BB86 1FDE 4046 0F83
FT, Debian-ylläpitäjä / PhD, Debian Maintainer

RE: Exporting a nonexistent variable

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 951 bytes --]

>I think Guile could report a warning if a nonexistent variable is 
>exported as the cause of this kind of errors may be difficult to find in 
>a large program.

During compilation, code is analysed and IIRC there is a warning for unbound variables. (I don’t know if warning is the default though.) Large program should be compiled, so they would get the warning.

So, just compile your modules and you should get warnings for the modules.
(I’m not sure about this particular (export this that) case – is it defining ‘this’ as ‘that’, or is it some kind of symbolic reference that can be created even if the target doesn’t exist? If the latter, maybe that’s not checked for for this warning – I don’t know.)

(Perhaps compilation actually happened, autocompilation is the default though it can be disabled – I don’t know if warnings are enabled for autocompiled dependencies though.)

Best regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 2252 bytes --]

Re: Exporting a nonexistent variable

[Tommi Höynälänmaa]

Here is another example:

--- mod1.scm ---
(define-module (mod1))

(export myproc)

(define (myproc0)
   (display "Hello\n"))

--- end ---

--- mod2.scm ---
(define-module (mod2))

(export myproc2)

(use-modules (mod1))

(define (myproc2)
   (display "Hello again\n"))

--- end ---

--- program.scm ---
(use-modules (mod1)
              (mod2))

(define (main args)
   (myproc))

--- end ---

I compiled this example with the following commands:

--- cut here ---

export GUILE_LOAD_COMPILED_PATH=.
guild compile --warn=unbound-variable -o mod1.go mod1.scm
guild compile --warn=unbound-variable -o mod2.go mod2.scm

--- cut here ---

The compiler gives no warnings and running "guile -e main -s 
program.scm" gives the following error:

--- cut here ---

;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /home/tohoyn/tyo/omat/ohj/scheme/export-test3/program.scm
;;; compiled 
/home/tohoyn/git/savannah/guile/cache/guile/ccache/3.0-LE-8-4.7/home/tohoyn/tyo/omat/ohj/scheme/export-test3/program.scm.go
Backtrace:
In ice-9/boot-9.scm:
   1762:12  4 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
            3 (apply-smob/0 #<thunk 7f2fda699300>)
In ice-9/boot-9.scm:
     731:2  2 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
     619:8  1 (_ #(#(#<directory (guile-user) 7f2fda69cc80>)))
In /home/tohoyn/tyo/omat/ohj/scheme/export-test3/program.scm:
       6:3  0 (main _)

/home/tohoyn/tyo/omat/ohj/scheme/export-test3/program.scm:6:3: In 
procedure main:
Unbound variable: myproc

--- cut here ---

      - Tommi Höynälänmaa

-- 
Kotisivu / Homepage: http://www.iki.fi/tohoyn/
Sähköposti / E-Mail: tommi.hoynalanmaa@iki.fi
GPG-sormenjälki / GPG fingerprint:
55F4 2477 7155 3528 5CB2 2B7A BB86 1FDE 4046 0F83
FT, Debian-ylläpitäjä / PhD, Debian Maintainer

RE: Exporting a nonexistent variable

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 72 bytes --]

I’ve send it to bug-guile, should appear in the issue tracker soon


[-- Attachment #2: Type: text/html, Size: 1101 bytes --]

RE: Exporting a nonexistent variable

[Maxime Devos]

[-- Attachment #1: Type: text/plain, Size: 12 bytes --]

#74210



[-- Attachment #2: Type: text/html, Size: 1090 bytes --]

Re: Exporting a nonexistent variable

[Tommi Höynälänmaa]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Thanks!

Maxime Devos kirjoitti 5.11.2024 klo 11.23:
>
> I’ve send it to bug-guile, should appear in the issue tracker soon
>
-- 
Kotisivu / Homepage:http://www.iki.fi/tohoyn/
Sähköposti / E-Mail:tommi.hoynalanmaa@iki.fi
GPG-sormenjälki / GPG fingerprint:
55F4 2477 7155 3528 5CB2 2B7A BB86 1FDE 4046 0F83
FT, Debian-ylläpitäjä / PhD, Debian Maintainer

[-- Attachment #2: Type: text/html, Size: 1523 bytes --]

Re: Exporting a nonexistent variable

[Attila Lendvai]

> I think Guile could report a warning if a nonexistent variable is
> exported as the cause of this kind of errors may be difficult to find in
> a large program.


you are exporting _symbols_ (unique identities) from modules, not variables (or bindings).

there are various use-cases where one wants to export a symbol from a module without binding any value to it in the module where it is being exported from.


> WARNING: (guile-user): `myproc' imported from both (mod1) and (mod2)


this^ is key, never ignore such warnings! i'd go as far as to suggest that this warning should be turned into an error. that would force the author to fix his package definitions to explicitly resolve such collisions.

sidenote: any serious codebase should compile with zero warnings, otherwise people start to ignore such warnings, they accummulate, and then waste precious programmer attention in debugging sessions.

our (Common Lisp) team used to have a running joke that if a situation just doesn't make any sense, then it must be a package (module) issue: `foo` and `foo` may print the same, but can be different identities.


> Backtrace:
> In ice-9/boot-9.scm:
> 1762:12 4 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
> 3 (apply-smob/0 #<thunk 7f3e3cd10300>)
> 
> In ice-9/boot-9.scm:
> 731:2 2 (call-with-prompt ("prompt") #<procedure 7f3e3cd22b00 …> …)
> 
> In ice-9/eval.scm:
> 619:8 1 (_ #(#(#<directory (guile-user) 7f3e3cd13c80>)))
> 
> In program.scm:
> 6:3 0 (main _)
> 
> program.scm:6:3: In procedure main:
> Unbound variable: myproc


there are two `myproc` symbols at play here, and you're trying to dereference the one that has no value bound to. you've been warned prior to this.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
You cannot wake up someone who is only pretending to be asleep.
	— Indian proverb

RE: Exporting a nonexistent variable

[Maxime Devos via Developers list for Guile, the GNU extensibility library]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

(My current e-mail client keeps corrupting guile-devel@gnu.org and refuses access to the contact list, please ignore wrong address)

>there are various use-cases where one wants to export a symbol [sic] from a module without binding [sic] any value to it in the module where it is being exported from.

Symbol -> variable, without binding any value -> without defining it to some value,  see https://www.gnu.org/software/guile/manual/html_node/Variables.html. Definedness and boundness are not the same thing.
(It’s annoying that after the introduction where it talks about definedness / boundness distinction, it gets things wrong again in the first procedure `make-undefined-variable` and later `variable-bound?’.) 

What use cases would this be?

All I can think of is:

>(define-module (a) #:export (b) (=>))
>(define b)
>(define-syntax => [something that makes compile-time error about this needing a syntax-parameterize)

In the first case, the variable ‘b’ is ‘undefined’. But it is still bound: an undefined variable is bound the symbol ‘b’ In the module ‘a’. In the second case, a variable with the name ‘=>’ is defined (and has the status of a macro), but only as a placeholder and except for error messages, it might as well have been undefined instead.

Neither of these is the situation in the original code, where the symbol wasn’t bound to any variable – no corresponding variable exists, whether defined or undefined (unless the ‘export’ implicitly creates variables, but that’s rather implicit and undocumented). And I don’t see any use case for that.

Would be interesting to investigate what RnRS has to say about the situation.

> WARNING: (guile-user): `myproc' imported from both (mod1) and (mod2)

>this^ is key, never ignore such warnings! i'd go as far as to suggest that this warning should be turned into an error. that would force the author to fix his package definitions to explicitly resolve such collisions.

Unless ‘myproc’ isn’t used (and it’s a whole module being compiled at once, not a REPL situation), then the import conflict wouldn’t matter. Could use a somewhat subtler approach.

Best regards,
Maxime Devos

[-- Attachment #2: Type: text/html, Size: 5143 bytes --]

Re: Exporting a nonexistent variable

[Mikael Djurfeldt]

[-- Attachment #1: Type: text/plain, Size: 2841 bytes --]

I think the wording in the Guile manual is unfortunate.

What RnRS says is that an identifier which is bound to a location is a
variable.

What the Guile manual is then discussing is our implementation details of
this, where "bound" is used in a different sense than in RnRS.

Den tors 14 nov. 2024 10:42Maxime Devos via Developers list for Guile, the
GNU extensibility library <guile-devel@gnu.org> skrev:

> (My current e-mail client keeps corrupting guile-devel@gnu.org and
> refuses access to the contact list, please ignore wrong address)
>
>
>
> >there are various use-cases where one wants to export a symbol [sic] from
> a module without binding [sic] any value to it in the module where it is
> being exported from.
>
>
>
> Symbol -> variable, without binding any value -> without defining it to
> some value,  see
> https://www.gnu.org/software/guile/manual/html_node/Variables.html.
> Definedness and boundness are not the same thing.
>
> (It’s annoying that after the introduction where it talks about
> definedness / boundness distinction, it gets things wrong again in the
> first procedure `make-undefined-variable` and later `variable-bound?’.)
>
>
>
> What use cases would this be?
>
>
>
> All I can think of is:
>
>
>
> >(define-module (a) #:export (b) (=>))
>
> >(define b)
>
> >(define-syntax => [something that makes compile-time error about this
> needing a syntax-parameterize)
>
>
>
> In the first case, the variable ‘b’ is ‘undefined’. But it is still bound:
> an undefined variable is bound the symbol ‘b’ In the module ‘a’. In the
> second case, a variable with the name ‘=>’ is defined (and has the status
> of a macro), but only as a placeholder and except for error messages, it
> might as well have been undefined instead.
>
>
>
> Neither of these is the situation in the original code, where the symbol
> wasn’t bound to any variable – no corresponding variable exists, whether
> defined or undefined (unless the ‘export’ implicitly creates variables, but
> that’s rather implicit and undocumented). And I don’t see any use case for
> that.
>
>
>
> Would be interesting to investigate what RnRS has to say about the
> situation.
>
>
>
> > WARNING: (guile-user): `myproc' imported from both (mod1) and (mod2)
>
>
>
> >this^ is key, never ignore such warnings! i'd go as far as to suggest
> that this warning should be turned into an error. that would force the
> author to fix his package definitions to explicitly resolve such collisions.
>
>
>
> Unless ‘myproc’ isn’t used (and it’s a whole module being compiled at
> once, not a REPL situation), then the import conflict wouldn’t matter.
> Could use a somewhat subtler approach.
>
>
>
> Best regards,
>
> Maxime Devos
>

[-- Attachment #2: Type: text/html, Size: 5209 bytes --]