Hello again,
> Brandon Invergo <bran...@invergo.net> writes:
>
>> I can try something like this:
>>
>> (let ((old-absolute-file-name? absolute-file-name?))
>> (define-generic absolute-file-name?)
>> (define-method (absolute-file-name? (f <file-name>))
>> (proper-list? (route f)))
>> (define-method (absolute-file-name? (f <string>))
>> (old-absolute-file-name? f)))
>>
>> But that strangely gives me this upon compiling the module:
>>
>> While compiling expression:
>> Unbound variable: absolute-file-name?
>>
>> I'm not sure what to make of that. A compile-time error, but why?
>
> It's because you tried to export a binding that doesn't exist at the
> top-level of your module.
I should explain more clearly what happened here. The short answer is:
When you export a variable, it immediately shadows any imported bindings
with the same name.
The longer answer is that before a variable can be exported, we first
need a variable object to add to the public interface. If you export a
variable before it has been defined (the usual case), Guile allocates a
fresh variable object and immediately adds it to the local module table,
although it marks the variable as "unbound", which essentially means
that the variable pretends not to exist. However, the existence of this
"unbound" variable *does* have the effect of hiding any imports with the
same name.
Mark
