[racket-dev] proposal: `data' collection

At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote:
> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > At Sat, 10 Jul 2010 09:35:28 -0500, Robby Findler wrote:
> >> Just to be sure I understand, you're saying that these two may or may
> >> not refer to the same file:
> >>
> >> >>   (require foo/blah)
> >> >>   (require "blah.rkt")
> >>
> >> right?
> >
> > Right --- depending on whether the enclosing file is required through a
> > `lib' path or through a `file' path, and when "blah.rkt" is shadowed in
> > an alternative collects directory.
> >
> > That much is true already if you shadow the "foo" collection through a
> > different "collects". Currently, I think the "blah.rkt" form will
> > always refers to a file in the same directory as the enclosing module,
> > but I'm not certain.
> 
> That seems like it matches the principle of least surprise: quote
> marks mean relative directories and things like (require foo/blah)
> mean "go find it in the collection tree". So the difference is
> syntactically apparent.

I agree that it's a nice property. I'm just not convinced that it's
crucial, and even if it holds now, maybe we can live without it in
exchange for collection splicing at the file level.

Along similar lines, various things can go wrong if there are multiple
paths to your main collects tree. I have "/home/mflatt" symlinked to
"/Users/mflatt" on my machine, and sometimes I end up referring to the
`racket' binary through one path while requiring a file through the
other path --- which breaks the expected correspondence between `file'
and `lib' paths. The "sandbox.rktl" test suite goes wrong when that
happens, for example, but I also hit other problems. I suppose I keep
my broken configuration just to maintain a sense of how often things go
wrong and how reasonable it is to try to defend against such problems.
So far, I'm left with the sense that defense against broken
configurations is too hard.