[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]