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.

Reply via email to