[racket-dev] proposal: `data' collection

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Fri Jul 9 15:10:26 EDT 2010

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.

 * The `collection-path' function would have to be deprecated, and we'd
   add a `collection-file-path' function that splices at the file
   level.

   Most uses of `collection-path' could be easily replaced with
   `collection-file-path'.

   Some other uses of `collection-path' don't particularly need
   splicing (e.g., locating a file used by a test suite).

   A Planet package (or some other code outside the main development
   repository) might use `collection-path' in a way that would break if
   a collection is spliced at the file level. If the package is useful
   enough, I imagine there will be plenty of time to fix it before
   file-level splicing becomes common.

Does anyone see a problem that I've overlooked?



Posted on the dev mailing list.