[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[FIXED:] Strange interaction of define-method with the module system
From: |
Dirk Herrmann |
Subject: |
[FIXED:] Strange interaction of define-method with the module system |
Date: |
Fri, 15 Dec 2000 15:01:07 +0100 (MET) |
On 30 Nov 2000, Mikael Djurfeldt wrote:
> Matthias Koeppe <address@hidden> writes:
>
> > I am trying to define an exported method FOO in the previously defined
> > module MURKS using the code below. The defined method will not be
> > visible in GUILE-USER although it uses the MURKS module. Note that the
> > symbol FOO naming the method is not unbound (it seeems to get bound to
> > #f in the GUILE-USER module).
> >
> > (I need this for making Guile work with ILISP, a generalized Emacs
> > interface to Lisp systems.)
> >
> > (define-module (murks)
> > :use-module (oop goops))
> >
> > (define-module (guile-user)
> > :use-module (oop goops)
> > :use-module (murks))
> >
> > (eval '(define-method foo ((a <integer>)) a) (resolve-module '(murks)))
> > (eval '(export foo) (resolve-module '(murks)))
> >
> > (foo 1) ; ==> ERROR: Wrong type to apply: #f
>
> This is not a result of interaction between define-method and the
> module system. It is a result of the module system only.
The problem is due to a bug in the implementation of scm_eval: scm_eval
passes the environment to scm_[cd]eval, but it does not update the global
fluid that is used by 'current-module. Thus, the evaluator uses the
correct environment, but any scheme code will get wrong answers from calls
to 'current-module.
A fix is in CVS. I ask people to take a look at it and try it
out. Testcases for the guile test-suite are also always welcome.
Best regards,
Dirk Herrmann
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [FIXED:] Strange interaction of define-method with the module system,
Dirk Herrmann <=