Eli, I do not understand and/or appreciate your objection.
Here is what I understand:
-- you believe that top-level collects are something coherent
Q: could you explain this? In what sense is lang/ more or less coherent
than data/
-- you introduce the notion of a package
Q: what is that and how does it differ from a collects?
-- Matthias
On Jun 30, 2010, at 9:44 PM, Eli Barzilay wrote:
> On Jun 30, Sam Tobin-Hochstadt wrote:
>> On Wed, Jun 30, 2010 at 9:02 PM, Eli Barzilay <e...@barzilay.org> wrote:
>>> On Jun 30, Sam Tobin-Hochstadt wrote:
>>>> On Wed, Jun 23, 2010 at 2:29 PM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu>
>>>> wrote:
>>>>> At the Northeastern PLT lunch today, I proposed adding a top-level
>>>>> `data' collection, for all manner of data structures.
>>>>
>>>> Based on the discussion,
>>>
>>> There was no discussion. I posted the main problem with that, which
>>> you never replied to.
>>
>> I don't believe you pointed out a problem. There was discussion was
>> of what sense of "core" we mean, which I clarified. As demonstrated by
>> the `syntax' collections, this doesn't pose a problem.
>
> Below is what wrote, which you replied to as if the only issue is the
> name of the collection. The name is just a symptom -- which will go
> away *if* we have a solution to separating collections. If not, then
> such a generic collection will be a problem regardless of the name.
>
> And just in case you'll want to ignore the actual content of this:
> (a) I'm not objecting to `data' as a name, (b) I *want* a good
> solution for this problem, and have wanted one for a while, (c) if
> there is a solution for this, then `data' (while not great) works
> as well as in the Haskell example you mentioned, but as things stand,
> it is a problem regardless of the name.
>
> -------------------------------------------------------------------------------
>
> Matthias said:
>
>> We could call it 'collections' hierarchy as in Java, but I don't
>> think that this is a good name. Ideally, I'd like to call it
>> data-structure but that isn't a good path element.
>
> +1 on both. `data' does seem to me better than both of these, but I
> still dislike it since it's a vague name like "etc". Here's an
> attempted clarification of what bothers me about it, and possibly
> something to think about before August.
>
> Currently, we use the toplevel collections as units of coherent pieces
> of code -- they match both how the code is layered (at least it
> should) and how it's distributed. Yes, the plan for a minimal
> distribution is still not concrete -- but we're already doing that.
> For example, planet's granularity is by collection, and the most of
> the distribution specs are in terms of collections too. The bottom
> line is that currently we have "top level collection" as something
> that roughly corresponds to "a package".
>
> Now, a name as generic as `data' is going outside of this role. It's
> likely to have in there general "core things" like `data/list' as well
> as specific things like some queue that is optimized for a specific
> task or perhaps a persistent set that is backed by a database.
> Because of this I view `data' as a bad choice -- at least as long as
> we have the current meaning of "a collection". Even if the decision
> was not made consciously, I think that the fact that the core data
> types are in the `racket' collection are a direct byproduct of this
> issue too. (There's also the fact that such libraries might need to
> behave differently -- for exaple, not getting an error in terms of
> `vector-length' when the original call was some Honu `x.length()'.)
>
> Perhaps the role of (toplevel) collections should change. More
> likely, it's about time we decide -- concretely -- on defining
> "packages". These would be relevant for planet, for minimizing the
> distribution, and a whole bunch of other issues that depend on this.
>
> It seems reasonable to define these packages somehow as either
> toplevel collections or complete subtrees of them, with some way of
> specifying which directory (or maybe a group of sibling directories)
> is the "root" of a package. But this requires modifying the current
> way that toplevel collections are spliced together -- for example, you
> should be able to get install a user-specific data/foo package
> (something that is not possible now).
>
> In that case, a generic name like `data' works out much better. Since
> that's a separate issue, my objection to `data' is based on the
> current state of the system.
>
> --
> ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
> http://barzilay.org/ Maze is Life!
> _________________________________________________
> For list-related administrative tasks:
> http://lists.racket-lang.org/listinfo/dev
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
