On Sat, Jul 10, 2010 at 9:59 AM, Matthew Flatt <[email protected]> wrote: > At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote: >> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt <[email protected]> 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.
What value does this have? If I'm not in a collection there's no splicing, right? If I am in a collection, I can choose which notation I use for the require and get the behavior I want, right? > 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. I agree with that. Robby _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
