Hello,

I see what you are trying to do, and I agree that it should be possible. I
have set up the same situation as you: trying to load a module, failing,
adding it to my path, trying again, and failing again. Here's what I've
figured out:

- resolve-module fails on the module, when I think it should succeed.
that's because
- try-autoload-module fails on the module, when again I think it should
succeed. and that's because
- autoload-done-or-in-progress? returns #t for the module, when I think it
should return #f. specifically, the module is marked as done, and therefore
try-module-autoload won't look for it any more.
- the module was marked as autoloaded because that's what
try-module-autoload does: it *always* marks its module as autoloaded, even
if it wasn't found.

As a workaround, remove your module from the list "autoloads-done".
(actually, there will be a pair in that list, where the cdr of the pair is
the name of the module as a string. remove that.)

In the long term, Andy and Ludo, what is the right way to fix this? Should
try-module-autoload not mark unfound modules as autoloaded? Or maybe there
should be a special function that says "retry this module, starting from
the beginning". Maybe it could even be part of reload-module.

Best,
Noah



On Fri, Jan 18, 2013 at 11:15 PM, Diogo F. S. Ramos <diogofsr@gmail.com>wrote:

> Nala Ginrut <nalaginrut@gmail.com> writes:
>
> > Why you need to load the module without giving its path?
>
> Sorry, I should have added some more context.
>
> While I'm working with the REPL, sometimes I forget to add the path to a
> module before trying to use it. It's a mistake. So, after trying to load
> the module with `use-modules', and failing, I remember that I have to
> add the path to the module. So I add the path to the module with
> `add-to-load-path' and I try again to evaluate
> `use-modules'. Unfortunately it does not load it and I'm stuck. To fix
> it, I end up restarting the REPL and adding the path _before_ trying to
> load it, as it's the right way to do it.
>
> Here is an example with my typical mistake:
>
> $ cat /tmp/foo/bar.scm
> (define-module (foo bar))
>
> (define-public (hello)
>   (display "hello, world")
>   (newline))
> $ guile
> GNU Guile 2.0.5-deb+1-1
> Copyright (C) 1995-2012 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> (use-modules (foo bar))
> While compiling expression:
> ERROR: no code for module (foo bar)
> scheme@(guile-user)> (add-to-load-path "/tmp")
> scheme@(guile-user)> (use-modules (foo bar))
> While compiling expression:
> ERROR: no code for module (foo bar)
> scheme@(guile-user)> (hello)
> ;;; <stdin>:4:0: warning: possibly unbound variable `hello'
> <unnamed port>:4:0: In procedure #<procedure e3f580 at <current input>:4:0
> ()>:
> <unnamed port>:4:0: In procedure module-lookup: Unbound variable: hello
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]>
>
> The question is: Is there a way to recover from this mistake in my live
> REPL session?
>
>