Curse my sausage fingers! That last send was unintentional. I've deleted it from the online Google Groups forum for the sake of future subscribers.
I can understand wanting to minimize the distinction and in some ways make all core language, standard libraries, and community libraries equal. For me the issue is software maintenance. If I'm building something that needs functionality from an external library, I'm more likely to choose a library from the standard install if one exists. I can be reasonably certain it will be supported for a long time into the future, and if it ever ceases to be supported it will likely be gracefully deprecated over the course of a few releases. Neither of those points are guaranteed, but I think they are reasonable assumptions to make. Also, to some extent there already is a distinction in the documentation. There is the section "Racket Language and Core Libraries", and then there is everything else. However, the libraries from the 'base' package and other shipped packages are sprinkled into the "everything else" docs and not all the shipped packages are listed under "Racket Language and Core Libraries". So it makes things murky. A possible compromise may be to have the top level page of http:// docs.racket-lang.org/ remain the same, but have a small link/page under http://docs.racket-lang.org/reference/ page that lists the links to all the packages/libraries/collections that are shipped by default with Racket. The pages that the links point to would all still live where they always have and still be listed at the top level http://docs.racket-lang.org/ the same way they already are. That way there is some centralized place to figure out what ships with racket without mucking around the filesystem after install, or checking on each link on http://docs.racket-lang.org/ to see if the package it requires from is 'base' or something else core to the install. To Stephen, thanks for sharing the articles from Eric Raymond. It made me think maybe I'm not just a crazy guy on the street corner wearing a burlap sack and a tin foil hat declaring the end of the world. Or, at the very least, I'm not alone on the street corner :) . -- Ethan Estrada On Jan 29, 2017 06:45, "Matthew Flatt" <mfl...@cs.utah.edu> wrote: At Sat, 28 Jan 2017 22:51:43 -0800 (PST), Ethan Estrada wrote: > My only real beef with the Racket docs are the layout of packages; > there is no clear distinction between docs for standard library items > and docs for community provided libs. That's intentional. I'd say that the absence of a line that distinguishes "Racket" from "not Racket" at the package level is an extrapolation of our goal to avoid a line between the "language" and "library" at the level of a module. There are certainly some drawbacks to allowing any old module to add new constructs to the programming language, but we think the benefits outweigh the drawbacks. Similarly, there are some drawbacks to allowing any old package to have the same status as the base system, but I believe in the benefits. In both cases, it's important that programmers have control over what is used and what isn't used. The module system enforces boundaries so that a module added to a program can't have an arbitrary effect on other modules in the program. Similarly, the package system is intended to give the programmer control over what packages are installed and how they are installed. I'm not objecting to improvement here --- just trying to clarify why the current organization is like that. Also, I'd concede that we have a notion of "main distribution", which identifies a set of packages that are included in the Racket installers at racket-lang.org. That's a useful concept, but I see it as a compromise, and I'm reluctant to reflect that distinction in the documentation. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.