[racket-dev] new package system collections and conflicts

Jay McCarthy wrote on 11/30/2014 12:30 PM:
> On Sunday, November 30, 2014, Neil Van Dyke <neil at neilvandyke.org 
> <mailto:neil at neilvandyke.org>> wrote:
>
>
>     Jay McCarthy wrote on 11/30/2014 12:13 PM:
>
>         The documentation cited is making clear that there is NO
>         connection between the name of a package and the provided
>         modules. There is no such thing as a package namespace.
>
>
>     I'd really like there to be.  For third-party packages.
>
>
> I do not know what a third party package is.

I'm thinking of *non*-core-Racket-developers.  Who have different needs 
than core Racket developers.  It's good that Racket is blurring the 
distinction, but the needs still aren't necessarily the same.  I say 
"third-party" as shorthand familiar to me, but perhaps there's a better 
term.


>
>
>         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, although this is just for the benefit of search and reading docs; 
> it has no technical enforcement.
>
>     If so, I don't understand why that would be considered a good idea.
>
>
> It is a principle to create general purpose reusable code in the 
> package ecosystem rather than little archipelagos with lots of private 
> code that gets duplicated and has clever names.


I keep wanting to encourage lots-and-lots of packages, and they can be 
packaged and released in a very lightweight yet well-conceived manner.

To go back to your example, if it's a useful general-purpose data 
structures library, then that's another package, which should be very 
easy to do.  If the package author isn't ready to split it out, then 
they're not ready to split it out, so no sense talking about it.  As far 
as I can tell, in no case is this `data` namespace relevant.

Side note: I really don't think ontological classification of package 
topics belongs in package names.  Topical classifications evolve over 
time, and independent of the objects themselves. Classifications belong 
in directories, not in names.

Neil V.