DrRacket bug producing incorrect namespace mismatch

[William J. Bowman]

I've encountered a weird bug in DrRacket (I think).
I've reproduced the bug in 6.10.1.2 and git HEAD (02f61622838ff28d447a76c344fe9e117ab5a306).

Attached are two files that differ only in the order of two definitions.
One produces a namespace mismatch error in DrRacket, the other does not.
Neither produces an error when running the files in any other way, such as in the emacs mode or on the
commandline.

The key ingredients appear to be:
1. Use require/expose from rackunit-lib
2. Define a macro that uses a phase-1 identifier
3. Define the phase-1 identifiers *after* defining the macro

--
William J. Bowman

[Leif Andersen]

FWIW, I've managed to shrink the example down even more. Now you only
need module*, and expose, and two begin-for-syntax blocks after that.

~Leif Andersen

> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20180201223310.GO14189%40williamjbowman.com.
> For more options, visit https://groups.google.com/d/optout.

[Robby Findler]

This seems to be how you make it happen outside of DrRacket:

$ racket -l errortrace -t namespace-mismatch.rkt
namespace-mismatch.rkt:11:9: require: namespace mismatch;
reference to a module that is not available
reference phase: 1
referenced module: 'expanded module
referenced phase level: 1
in: do-something-at-phase-1
errortrace...:
context...:
standard-module-name-resolver

> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAAVaeEDqkD171R_%2B-XSPb%2BmVaiWRMyjyN3cq0CitVvxYysnESA%40mail.gmail.com.

[Leif Andersen]

OH, also, I should mention that it only breaks when using errortrace.
Running it without errortrace seems to work.

~Leif Andersen

[Leif Andersen]

And one more time, after manually expanding what require/expose does,
it looks like its the dynamically adding a binding into the module's
namespace that is messing it up. Micheal Ballentyne points out that
this error does not occur in Racket 7, even when using errortrace. So
I'm not sure if this is a bug in Racket 6, or an intended behavior.

~Leif Andersen

[Michael Ballantyne]

An even slightly smaller version is attached.

[Leif Andersen]

Oh interesting. This even happens when DrRacket has debugging turned
off, which seems to indicate that its not a problem with errortrace,
but a bug in the expander that shows up when using the sort of
re-expansion technique that both DrRacket and errortrace use.

~Leif Andersen

> https://groups.google.com/d/msgid/racket-dev/fbc1b9de-e34b-49d7-9686-e7aabb9a8fd4%40googlegroups.com.

[Leif Andersen]

And just to confirm that this is related to re-expansion, I can
duplicate the error by just calling `expand` twice on the file:

#lang racket

(define the-prog
(file->value "namespace-mismatch.rkt"))
(current-namespace (make-base-namespace))

(expand (expand the-prog))

~Leif Andersen

[Matthew Flatt]

William: Do you have a workaround for now, such as reordering the
definitions?

I have a change that makes these examples work, but it breaks other
examples, like a single expansion of this module:

(module namespace-mismatch racket/base
(#%plain-module-begin

(#%require (for-syntax racket/base))

(begin-for-syntax
(let ([ns (variable-reference->namespace (#%variable-reference))])
;; The top level at phase 1 ...
(eval #'(define-syntax-rule (m) (begin (define x 2) x)) ns)
;; The expander will have to find the right macro-introduced `x`:
(eval #'(m) ns))
(#%plain-lambda () foo))

(begin-for-syntax
(define-values (foo) #f))

(module* f #f
(#%plain-module-begin))))

The problem is that the current expander tries to do different things
in a module and at the top level to handle macro-introduced
identifiers. That seems ok for phase 0, where a module and top-level
process don't overlap for the same namespace, but these examples
illustrate how it fails for phase 1.

The change to make other examples work is at

https://github.com/mflatt/racket/tree/phase-1-ns

Since it may break existing programs, though, I'm reluctant to push it.

The right solution is to switch to the new expander implementation ---
soon, I hope. The new expander works on all of these examples, and it
generally gets `...->namespace` operations right where the current
expander's implementation is flaky.

Thanks all for very helpfully narrowing down the problem!

[William J. Bowman]

On Sat, Feb 03, 2018 at 08:34:00AM -0700, Matthew Flatt wrote:
> William: Do you have a workaround for now, such as reordering the
> definitions?

Yes, reordering definitions and/or not using DrRacket is a good enough for now.

Thanks for your explanation and work on this; looking forward to the new expander!

--
William J. Bowman