Re: [racket-dev] new package system collections and conflicts

Thanks for being with with us for so long. I think you misunderstood the word 'charity' here and perhaps Jay could have used a different, a more appropriate word than 'charity', which I now realize can have a negative connotation. Otherwise, I think that the package system design is about re

Re: [racket-dev] new package system collections and conflicts

I think there is perhaps a misunderstanding. The design of the pkg system is (partly) driven by the observations the core team has about what gives us special privilege and then working to lift those restrictions so we don't need to operate under that special privilege. And I'll note that this the

Re: [racket-dev] new package system collections and conflicts

I don't think I need charity. I thought the vision for the new package system had already been explained adequately. I would be very interested to learn how the model is well-suited to third-party developers like me. But -- I mean this constructively -- I'd be happy if someone simply came o

Re: [racket-dev] new package system collections and conflicts

Your frustration is understandable given the lack of charity I've shown in this thread. I apologize and promise to try to be better. I know I'm repeating myself annoyingly, but I think the most productive way to move forward is if you could identify problems that you're trying to solve where the p

Re: [racket-dev] new package system collections and conflicts

I think this "what's the matter with conflicts, and an arbitrary package putting things wherever it wants, and not having a notion of non-backward-compatibility" is similar to "what's the matter with using eval for everything" or "what's the matter with defmacro" or "what's the big deal about h

Re: [racket-dev] new package system collections and conflicts

To play the role of Mr. Anecdote: Someone mentioned Cabal. Last week at Hacker School, I paired for a few hours with someone more-experienced in Haskell, to try using Template Haskell on a toy project I'd done. My project uses Pandoc. Apparently Pandoc is felt to download half the internet's worth

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:40 PM, Neil Van Dyke wrote: > > Jay McCarthy wrote on 11/30/2014 12:30 PM: >> >> On Sunday, November 30, 2014, Neil Van Dyke > > wrote: >> >> >> Jay McCarthy wrote on 11/30/2014 12:13 PM: >> >> The documentation cited is making cl

Re: [racket-dev] new package system collections and conflicts

Just to be clear. I don't think that "tic-tac-toe" and "data/matrix" are the important thing in this example. The important thing is that the package name and the module don't share a prefix. Another good example would be something like "graphs" and "data/fib-heap" or something where it may to be e

Re: [racket-dev] new package system collections and conflicts

Sam Tobin-Hochstadt wrote on 11/30/2014 12:52 PM: 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

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke 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 c

Re: [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 > 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

Re: [racket-dev] new package system collections and conflicts

On Sunday, November 30, 2014, Neil Van Dyke 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

Re: [racket-dev] new package system collections and conflicts

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. Packages may find it

Re: [racket-dev] new package system collections and conflicts

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. Jay On Sunday, November

Re: [racket-dev] new package system collections and conflicts

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. Packages may find it convenient to build and provide reusable functionality with many organizational names. This is particularl

Re: [racket-dev] new package system collections and conflicts

Sam Tobin-Hochstadt wrote on 11/30/2014 10:55 AM: Another example where this happens (and in a way that couldn't be fixed by combining packages) is with typed versions of libraries. If I release a package with the collection `foo`, and then someone else produces a typed version of it, that will p

Re: [racket-dev] new package system collections and conflicts

On Sun, Nov 30, 2014 at 10:44 AM, Matthew Flatt wrote: > > 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 a

Re: [racket-dev] new package system collections and conflicts

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 ar

[racket-dev] new package system collections and conflicts

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