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
