bug in "imports obarray"?

[Andy Wingo]

Hi,

Consider the following module:

    (define-module (ice-9 curried-definitions)
      #:replace ((cdefine . define)
                 (cdefine* . define*)))

    (define-syntax cdefine
      (syntax-rules ()
        ((_ ((head . tail) . rest) body body* ...)
         (cdefine (head . tail)
           (lambda rest body body* ...)))
        ((_ (head . rest) body body* ...)
         (define head
           (lambda rest body body* ...)))))

    (define-syntax cdefine*
      (syntax-rules ()
        ((_ ((head . tail) . rest) body body* ...)
         (cdefine* (head . tail)
           (lambda* rest body body* ...)))
        ((_ (head . rest) body body* ...)
         (define* head
           (lambda* rest body body* ...)))))


If, at the repl, I do a (use-modules (ice-9 curried-definitions)), I
would expect my `define' to recognize the currying syntax.

What in fact happens, at my repl at least, is that though the module is
correctly added to the imports list, when looking for the value for
`define' in `(define ((foo)) 42)' we hit the memoized case in
module_imported_variable:

    /* Lookup SYM as an imported variable of MODULE.  */
    static inline SCM
    module_imported_variable (SCM module, SCM sym)
    {
    #define SCM_BOUND_THING_P scm_is_true
      register SCM var, imports;

      /* Search cached imported bindings.  */
      imports = SCM_MODULE_IMPORT_OBARRAY (module);
      var = scm_hashq_ref (imports, sym, SCM_UNDEFINED);
      if (SCM_BOUND_THING_P (var))
        return var;
here ^^

      {
        /* Search the use list for yet uncached imported bindings, possibly
           resolving duplicates as needed and caching the result in the import
           obarray.  */
        ...

I'm pretty sure this is a bug. We should have module-use! clear entries
from the cache -- all entries, probably. The normal case is for all
module-use! statements to be executed before before the module is made
current.

This could affect any cached variables in procedures, but I think we can
ignore that in this case.

Andy
-- 
http://wingolog.org/