Re: Exporting a nonexistent variable

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 <[email protected]> skrev:

> (My current e-mail client keeps corrupting [email protected] 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
>