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? Robby On Sat, Jul 10, 2010 at 9:07 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > At Sat, 10 Jul 2010 01:48:09 -0400, Eli Barzilay wrote: >> On Jul 9, Matthew Flatt wrote: >> > At Wed, 30 Jun 2010 22:28:48 -0400, Eli Barzilay wrote: >> > > Back to `data', the problem is that you cannot have two toplevel >> > > `data' collections -- which means that you cannot have separate >> > > distributions of `data/foo' and `data/bar' since they must both >> > > appear in your plt installation or in your user directory -- not >> > > in both. >> > >> > The more I think about it, the more I'm convinced that it's ok to >> > splice collections at the file level instead of the directory level: >> > >> > * Splicing at the file level doesn't create any issues for >> > resolving module names: There's already a search path to find the >> > directory for a collection, and the filename is known at that >> > point, so the filename could be used as part of the search. >> >> Was there an issue of efficiency? > > I don't think so. > >> Also, I think that there was a >> potential issue with, for example, "collects/foo/bar.rkt" having: >> >> (require foo/blah) >> (require "blah.rkt") >> >> not have the same meaning, since the first would search for the file >> in all roots, and the second is always in the same directory. So >> assuming those would be different, there should be a scan on all >> requires in the tree, making sure that the appropriate style is used. > > Using "blah.rkt" wouldn't always mean the "blah.rkt" in the same > directory, due to the occasional need for module-path collapsing (as > opposed to module-path resolution). That is, neither style of `require' > would avoid the possibility that "blah.rkt" comes from a different > directory or that there will be a mess if it exists in multiple places. > > On points like this, I came to the conclusion that users can just break > things with bad collection configurations. Similar bad things can > happen with "info.rkt" files. Maybe `raco setup' should perform a > sanity check, but I don't think we can rule out this kind of confusion > by design within our current constraints. > > _________________________________________________ > For list-related administrative tasks: > http://lists.racket-lang.org/listinfo/dev > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
