[racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke <neil at neilvandyke.org> wrote:
>
>>
>> Packages may find it convenient to build and provide reusable
>> functionality with many organizational names. This is particularly true of
>> "data", as many packages may have useful data structures.
>>
>> Of course, as such support code becomes very useful and developed, it
>> makes sense to sprin it off into its own package.
>
> Are you saying that `data` is some kind of classification of "what this
> module is about", and in this case specifically, "this module, which is part
> of some more specific package, happens to be regarding general-purpose data
> structures, so we're putting it over here in the `data` area of a shared
> namespace hierarchy"?

Yes, the idea is that it makes sense for `data/hamt` to come from the
"hamt" package, and for `data/fector` to come from the "fector"
package (this is currently the case on pkgs.racket-lang.org).

>  If so, I don't understand why that would be
> considered a good idea.

Because the client of these modules shouldn't have to think about
which package they belong in to use them. This gives the package
developer freedom to combine or split packages without requiring code
changes from clients. In general, one of the assumptions of the new
package system is that metadata changes, such as dependencies, are
easier to manage than code changes. This assumption is fairly
pervasive in successful package systems, including extra-linguistic
ones such as dpkg as well as in-language ones such as Cabal and npm.

The particular mode of use, where module names splice, has been
successful in a number of other communities, such as Haskell, where
they have just such a Data hierarchy, and where, like in Racket,
package names and module names aren't connected. This is also the case
in Java packages, although the naming scheme is somewhat different.

Sam