Re: [racket-dev] Package compatibility
Yesterday, Jay McCarthy wrote: Planet attempts to solve this problem technically by (a) having all collections be prefixed by author/package-name and (b) mandating a centralized server that enforces unique authors and unique package-names per author. Since Racket packages don't have a mandated central server we can't enforce uniqueness like that. (i.e. even if we mandated the prefix by package-name, there's no way to enforce unique package names across the universe without a central server.) Furthermore, bringing package-names in to the code would give us /internal linking/ which Racket packages are designed to avoid for other reasons. Since technical solutions to this problem are lacking, An easy way to make it a non problem would be to eliminate the extra indirection that is in package names: if the package that Carl is asking about is *named* data/red-black-tree then it clearly conflicts with another package with the same name. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
The problem with that is that there is no way to ensure that there is only one package named data/red-black-tree and there can be two mutually incompatible universes of packages for Carl's rbts and mine, for instance. Furthermore, it has the internal linking problem. On Mon, Jul 8, 2013 at 7:11 AM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Jay McCarthy wrote: Planet attempts to solve this problem technically by (a) having all collections be prefixed by author/package-name and (b) mandating a centralized server that enforces unique authors and unique package-names per author. Since Racket packages don't have a mandated central server we can't enforce uniqueness like that. (i.e. even if we mandated the prefix by package-name, there's no way to enforce unique package names across the universe without a central server.) Furthermore, bringing package-names in to the code would give us /internal linking/ which Racket packages are designed to avoid for other reasons. Since technical solutions to this problem are lacking, An easy way to make it a non problem would be to eliminate the extra indirection that is in package names: if the package that Carl is asking about is *named* data/red-black-tree then it clearly conflicts with another package with the same name. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
Just now, Jay McCarthy wrote: The problem with that is that there is no way to ensure that there is only one package named data/red-black-tree There's no need to ensure such a thing -- and IIUC, the current system doesn't do that neither modulo a bunch of blessed packages. and there can be two mutually incompatible universes of packages for Carl's rbts and mine, for instance. This is also something that could happen now in the same way. But I don't see anything wrong with having this ability: I can hack my own racket/list to do whatever I want, and therefore I should be able to make a package that has this hacked version of the file. I'd be mostly living in my own world whether this hack is done with a package system or directly. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Package compatibility
It seems to me our new package system runs into trouble if two people write packages that use the same connection name. Let's say we have two packages, alice-tree and bob-tree, both of which provide the collection data/red-black-tree, but both provide different interfaces (perhaps similar functionality with different naming conventions). It seems to me this is not that unlikely to happen, but once it does, those two packages are completely incompatible. They can never meaningfully be installed on the same system, and if they are, the behavior of any code depending on either becomes undefined. Have I got this right, or have I missed some detail? If this is right, how concerned are we about this feature? The fact that packages are all spliced into a single flat collection namespace of course leads to the possibility of clashes like this, which can cause not just incompatibility between alice-tree and bob-tree, but a complete schism wherein all code depending on alice-tree at any level of indirection becomes completely disjoint from all code depending on bob-tree at any level of indirection. I've seen this kind of library incompatibility before, in the ACL2 books, and I wrote a dissertation to try to solve it. I hope we're not repeating their mistake, but it seems like we have yet another flat namespace with no resolution mechanism. Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Package compatibility
On Sun, Jul 7, 2013 at 11:44 AM, Carl Eastlund c...@ccs.neu.edu wrote: It seems to me our new package system runs into trouble if two people write packages that use the same connection name. Let's say we have two packages, alice-tree and bob-tree, both of which provide the collection data/red-black-tree, but both provide different interfaces (perhaps similar functionality with different naming conventions). It seems to me this is not that unlikely to happen, but once it does, those two packages are completely incompatible. They can never meaningfully be installed on the same system, and if they are, the behavior of any code depending on either becomes undefined. Have I got this right, or have I missed some detail? You are correct. If this is right, how concerned are we about this feature? The fact that packages are all spliced into a single flat collection namespace of course leads to the possibility of clashes like this, which can cause not just incompatibility between alice-tree and bob-tree, but a complete schism wherein all code depending on alice-tree at any level of indirection becomes completely disjoint from all code depending on bob-tree at any level of indirection. I've seen this kind of library incompatibility before, in the ACL2 books, and I wrote a dissertation to try to solve it. I hope we're not repeating their mistake, but it seems like we have yet another flat namespace with no resolution mechanism. Planet attempts to solve this problem technically by (a) having all collections be prefixed by author/package-name and (b) mandating a centralized server that enforces unique authors and unique package-names per author. Since Racket packages don't have a mandated central server we can't enforce uniqueness like that. (i.e. even if we mandated the prefix by package-name, there's no way to enforce unique package names across the universe without a central server.) Furthermore, bringing package-names in to the code would give us /internal linking/ which Racket packages are designed to avoid for other reasons. Since technical solutions to this problem are lacking, I/we/PLT (depending on the level of agreement with this idea) are trying to solve this problem socially by rewarding package authors (who list their packages on the PLT run server) with the ring system. Ring 1 packages can't conflict with each other and my desire is for only ring 1 and 0 packages to be listed in the DrRacket GUI. Ring 0 packages can't conflict with each other and must be good (have documentation, tests, etc). The goodie they get is that their packages will be tested with DrDr and we'll build their documentation and include it on the main site. Jay Carl Eastlund _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
