[racket-dev] proposal: `data' collection

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?  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.


>  * 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.

This seems reasonable to me.


> Does anyone see a problem that I've overlooked?

I don't see anything else.


[

But a related question is preparing for some definition of "package"
(not in the highlevel sense, but in a concrete way as info files were
kind-of used as).  It might be related to the way requires work or
something like that.  For example, something that I thought about
recently: maybe it makes sense to have a rule that "private"
directories can appear *only* in relative string requires that do not
have ".." parts in them.  I think that this would rule out any
"unauthorized" use of such modules in a simple way -- and perhaps this
can be extended somehow to create packages on in a similar way.

]

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!