[racket] Weird bug/feature with require, raco links, and xinit

Hi,

I've just been badly bitten by some strange 'require' behavior that took me
several hours to track down. I don't know if it's a feature or a bug, but
just in case let me share it. And if anyone has an explanation, that'd be
informative.

Long story short:

If you 'raco link my-dir' and sometimes (require my-dir/my-file) and other
times (require "my-file.rkt"), you may get into trouble... if you run it
via xinit (there may be other cases though).
It looks like the two require forms makes my-file's "visibility" (or
whatever the correct technical term is) differ.

Long story:

Say I have a module base.rkt exporting the parameter p with initial value
"base".
base.rkt:
#lang racket/base
(provide p)
(define p (make-parameter "base"))

Module a.rkt (in the same directory) require's base.rkt, changes p value to
"a", and require's b.rkt.
a.rkt:
#lang racket/base
(require "base.rkt"
         "b.rkt")
(p "a")
(printf "p in a.rkt: ~a\n" (p))
(b-print-p)

The required module b.rkt just prints the value of parameter p.
b.rkt:
#lang racket/base
(require "base.rkt")
(provide b-print-p)
(define (b-print-p)
  (printf "p in b.rkt: ~a\n" (p)))


Then if you simply:
$ racket a.rkt
things go as I would expect, i.e., it prints:
p in a.rkt: a
p in b.rkt: a
which is fine.

Now do the following:
- Let A be the directory which contains a.rkt, b.rkt, and base.rkt. Do:
$ raco link A
in A's parent directory.
- In file b.rkt (and only in b.rkt), change (require "base.rkt") to
(require A/base)
- write (and this is necessary apparently):
racket a.rkt
in you .xinitrc file (as the only line)

Now if on a login shell you type:
$ xinit -- :1
you should get:
p in a.rkt: a
p in b.rkt: base
which does not look fine.

Notes:

If you try:
$ racket a.rkt
You have the correct "a\na" output.

Also, if you replace "base.rkt" by A/base in a.rkt, all is fine too.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20121102/1ee431b5/attachment.html>