[racket-dev] proposal: `data' collection

On Sat, Jul 10, 2010 at 9:59 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Sat, 10 Jul 2010 09:49:31 -0500, Robby Findler wrote:
>> On Sat, Jul 10, 2010 at 9:47 AM, Matthew Flatt <mflatt at cs.utah.edu> 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