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 >
