I do not think we should change the example. I do not want people to falsely believe that they can any expectation of the modules provided by a package from its name. In particular, your comment about this being "strange" is not supported by the package system's promises. <div> </div><div>Jay On Sunday, November 30, 2014, Matthew Flatt <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We should change that example. It would indeed be strange for package named "tic-tac-toe" would introduce a `data/matrix` module, and the documentation really shouldn't suggest that it makes sense for a package to introduce overlaps that are not reasonably expected from the package name. There are plenty of real examples where it's sensible for different packages to introduce modules in overlapping collections, though. Sometimes, it's because different packages implement different facets of a conceptual whole, such as "math-lib", "math-doc", and "math-test" all extending the "math" collection. Sometimes, it's more a mater of history, such as "compatibility-lib" extending several different collections. And then there are example that you might classify as either of those or as a third kind, depending on how you look at it: "draw-lib" adds `racket/draw`, and "gui-package-manager" adds `pkg/gui`. The "data" collection is among those that were intended to be extended by multiple packages. Whether that's really a good idea remains to be seen, but that's why "data" shows up as an example in the manual. (Again, though, no one would expect a "tic-tac-toe" package to introduce a new module in "data".) At Sun, 30 Nov 2014 10:22:49 -0500, Neil Van Dyke wrote: > Given the example from the documentation, of the `tic-tac-toe` package > and "conflicts" (quoted at end of this email), instead, why isn't the > norm to do: > > (require tic-tac-toe) > > Or, when necessary: > > (require tic-tac-toe/matrix) > > Why, when one installs a package named `tic-tac-toe`, would one be > referencing modules of the package as `data/matrix`? > > I don't recall ever seeing a situation in which I wanted different > third-party Racket packages to be stomping over each other's > module-naming namespaces. > > For people who want to release lots of well-behaved reusable packages, > using good practices, with minimal effort and head-scratching, things > like this are a problem. > > > 2 Package Concepts > > > > A package is a set of modules in some number of collections. Modules > > installed using the Racket package manager are required like any other > > modules. For example, if the package tic-tac-toe contains the module > > "matrix.rkt" in a "data" collection, then after tic-tac-toe is installed, > > > > (require data/matrix) > [...] > > 2.5 Package Conflicts > > > > Two packages are in conflict if they contain the same module. For > > example, if the package tic-tac-toe contains the module file > > "data/matrix.rkt" and the package factory-optimize contains the module > > file "data/matrix.rkt", then tic-tac-toe and factory-optimize are in > > conflict. > > > > A package may also be in conflict with Racket itself, if it contains a > > module file that is part of the base Racket implementation. For > > example, any package that contains "racket/list.rkt" is in conflict > > with Racket. > > > > For the purposes of conflicts, a module is a file that ends in ".rkt", > > ".ss", or ".scrbl". > > Neil V. > > _________________________ > Racket Developers list: > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> _________________________ Racket Developers list: <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div> -- Jay McCarthy <a href="http://jeapostrophe.github.io" target="_blank">http://jeapostrophe.github.io</a> "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33