RE: Exporting a nonexistent variable

[Maxime Devos via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org>]

[-- 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 --]