Referencing a variable before importing it, causes identifier conflict about ikarus HOT 6 CLOSED

I knew about this problem. Let's wait until the brainstorming session on friday to see what the best way to resolve the repl issues.

Launchpad Details: #LPC Abdulaziz Ghuloum - 2007-11-14 21:48:48 -0500

from ikarus.

There is a hack that I just thought of that might push this problem further.

The expander could be made to allow importing an identifier that exists in the top level but whose value is not yet defined. So, you won't get hosed in the example you mentioned, but you'd still get weird results if you do:

(define (bar) foo)
(bar)
Error, foo is unbound
(import (import-bug))
foo
1 ;;; we're cool
(bar)
Error, foo is unbound!!!!
(define (bar) foo)
(bar)
1 ;;; we're cool again?

I don't know if this is better. What do you think?

Launchpad Details: #LPC Abdulaziz Ghuloum - 2007-11-26 05:00:28 -0500

from ikarus.

Does your example amount to there being two different "foo"? The first one is the "unbound" foo that exists until the import and the second one is from the library. Thus the first bar will always point at unbound-foo and it doesn't get changed until the redefinition which references library-foo. Is that the right way to understand it?

What about an example like:

(define (bar) foo)
(import (import-bug))
(bar)
;;; Are we cool??

If top level imports behaved similar to top-level recursive defines, the mental model might be easier to work with. Consider the examples:

(define (bar) foo)
(define (foo) bar)
(foo)
#
(bar)
#

(define (bar) foo)
(bar)
Error, foo unbound!!
(define (foo) bar)
(bar)
#
;; We're cool

Launchpad Details: #LPC Michael D. Adams - 2007-11-26 11:03:11 -0500

from ikarus.

On Nov 26, 2007, at 11:03 AM, Michael D. Adams wrote:

Does your example amount to there being two different "foo"? The
first
one is the "unbound" foo that exists until the import and the
second one
is from the library. Thus the first bar will always point at unbound-
foo and it doesn't get changed until the redefinition which references
library-foo. Is that the right way to understand it?

I think that's what I meant, yes. Basically, an import brings the
imported variables into scope. It does not mutate the existing
bindings.

What about an example like:

(define (bar) foo)
(import (import-bug))
(bar)
;;; Are we cool??

With what I'm suggesting, you'd get an unbound variable error since
foo is unbound.

If top level imports behaved similar to top-level recursive
defines, the
mental model might be easier to work with. Consider the examples:

It might be, but there are always some corner cases. What will
happen in the following case?

(define (set-foo! x) (set! foo x))
(define (get-foo) foo)
(import (import-bug)) ;;; this currently fails, but if we make
it pass, ...
foo
1 ;;; this would have to be 1
(get-foo)
1 ;;; should this be an error, or should it
be 1?
(set-foo! 17) ;;; now what? Which foo has changed?
(get-foo)
???
foo
???

Note that we haven't even gotten into the issues with macros yet :-)

Launchpad Details: #LPC Abdulaziz Ghuloum - 2007-11-26 19:47:52 -0500

from ikarus.

Not sure on the progress of this but here is another example:

Ikarus Scheme version 0.0.2patched+ (revision 1285, build 2007-12-24)
Copyright (c) 2006-2007 Abdulaziz Ghuloum

bar
Unhandled exception
Condition components:

1. &assertion
2. &who: eval
3. &message: "unbound variable"
4. &irritants: (bar)
   (library (foo) (export bar) (import (rnrs)) (define bar #t))
   (import (foo))
   Unhandled exception
   Condition components:
   1. &who: import
5. &message: "identifier conflict"
6. &syntax:
   form: (import (foo))
   subform: bar

Launchpad Details: #LPC leppie - 2007-12-27 10:39:30 -0500

from ikarus.

Wow! Finally! Fixed in revision 1459.

Launchpad Details: #LPC Abdulaziz Ghuloum - 2008-05-01 04:33:53 -0400

from ikarus.