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

2014-12-03 Thread Jay McCarthy
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

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

2014-12-03 Thread Neil Van Dyke
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

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

2014-12-03 Thread Robby Findler
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

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

2014-12-03 Thread Matthias Felleisen
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: [racket-dev] new package system collections and conflicts

2014-12-02 Thread Neil Van Dyke
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 having

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

2014-12-01 Thread Greg Hendershott
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

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

2014-11-30 Thread Matthew Flatt
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

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

2014-11-30 Thread Sam Tobin-Hochstadt
On Sun, Nov 30, 2014 at 10:44 AM, Matthew Flatt mfl...@cs.utah.edu 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

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

2014-11-30 Thread Neil Van Dyke
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

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

2014-11-30 Thread Jay McCarthy
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

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

2014-11-30 Thread Jay McCarthy
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

2014-11-30 Thread Neil Van Dyke
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

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

2014-11-30 Thread Jay McCarthy
On Sunday, November 30, 2014, Neil Van Dyke n...@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.

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

2014-11-30 Thread Neil Van Dyke
Jay McCarthy wrote on 11/30/2014 12:30 PM: On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org mailto:n...@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

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

2014-11-30 Thread Sam Tobin-Hochstadt
On Sun, Nov 30, 2014 at 12:23 PM, Neil Van Dyke n...@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

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

2014-11-30 Thread Neil Van Dyke
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

2014-11-30 Thread Jay McCarthy
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 easier

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

2014-11-30 Thread Jay McCarthy
On Sun, Nov 30, 2014 at 12:40 PM, Neil Van Dyke n...@neilvandyke.org wrote: Jay McCarthy wrote on 11/30/2014 12:30 PM: On Sunday, November 30, 2014, Neil Van Dyke n...@neilvandyke.org mailto:n...@neilvandyke.org wrote: Jay McCarthy wrote on 11/30/2014 12:13 PM: The