Re: [Texmacs-dev] file-exists? name conflict (was: Bad crash)

[Nix N. Nix]

On Wed, 2003-05-07 at 01:43, David Allouche wrote:
[...]
> By looking that your patch, I can see that guile-dialect detection is
> not the problem (your fix affects the guile-b branch of the dialect
> test).
> 
> Yet I am unsure that is really correct.
> 
> Here the old code:
> 
> (if (guile-a?)
>     (set! file-exists?
>         (let ((guile-file-exists? file-exists?))
>           (lambda args
>             (if (null? (cdr args))
>                 (apply guile-file-exists? args)
>                 (apply texmacs-file-exists? args)))))
>     (define file-exists? texmacs-file-exists?))
> 
> Here the new code:
> 
> (if (guile-a?)
>     (set! file-exists?
>           [same stuff here]
>     (set! file-exists? texmacs-file-exists?))
> 
> The problem is, if not guile-a? then symbol 'file-exists?' is
> supposedly not bound at this point. So 'set!' is not really correct.

Well, it worked for me, so I didn't think much of it.

> Actually, the problem with set! is that you may be setting a variable
> in the guile module (which is always visible) thus reverting back to
> the name conflict situation we had before: internal guile functions
> are using texmacs-file-exists? instead of guile's primitive.

I understand how this could be bad.  However, could we not change
texmacs-file-exists? to check for the number of arguments, then call the
guile version of file-exists? if there is only one.  We are (sort of)
doing it in the current code, but for a different dialect.  If we moved
the check into texmacs-file-exists?, we could /always/ overwrite the
guile version - of course, assuming that once we overwrite it, we can
still access the guile version (maybe via C++).

> 
> But the problem with 'define' may be that a binding is created in the
> module (core boot compat) and not exported to (guile-user).
> 
> In addition, since the binding is *not always* created in (core boot
> compat), we may not add 'file-exists?' to the public interface of the
> module without breaking the current convention that a module interface
> is completely set in the texmacs-module expression.
> 
> Well maybe we could do so... but exporting a symbol which is not
> defined in the current module is not really what I would call clean.
> 
> So the correct fix is probably to load compat.scm with
>     (exec-file "$TEXMACS_PATH/progs/core/boot" "compat.scm")
> instead of inherit-modules.

Got to love it when they change the signature of a function :o)