[racket-dev] haskell's 'hell of a lot of libraries', planet

Thanks Matthias - please see inline.

On Tue, Jul 27, 2010 at 7:03 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> 1. a 'remote url' require (which is what Planet boils down to) imposes a
> serious cost overhead (for compilation) and a connectivity overhead (suppose
> I send you code and you wish to compile it on your netbook while on the
> subway). People who get this kind of code should be aware of it. At a
> minimum, the path should start with /planet/  and that'll set it apart.
> (There's more, such as versioning.)
>

Location non-transparency matters a lot in remote API calls since each calls
incurs non-trivial network overhead.  However, the 'remote url' require is
only remote the *very first time*; once compiled it exists in cache and
hence incur no additional overhead.  Whereas the planet prefix incur the
awareness overhead every single time.  I.e., the cost is greater than the
benefit.

Other package systems separate the installation step from the import step,
and in such systems the subsequent use of the package appears exactly the
same as a local package.

If we want `require` to continue to handle both first-time install and
subsequent import, and we wish to unify the syntax, then what we can do is
to make the first time "interactive" - i.e. when we require a package that
has not been cached, we can prompt the user saying "this package resides on
planet - do you wish to download and continue the installation?".  There are
probably better UI approaches, but that's an idea.

For versioning - any explicit version can be cached in planet style, and all
version exists on planet systems.  What this means is once planet and
collects unify, you can have the different versions of collects packages
living in planet.



> 2. it is easy to find and fix collects code. Planet's download mechanism
> would have to change a lot to enable that.
>
>
This is the cultural issue that I am talking about.  To use other people's
code there needs to be trust that other people's code will be supported.
 The trust won't be built over night, but you also will not start using
other people's code en masse.  So there is time to build that trust.

At first, most likely you will only try out a few packages, and probably
from people that are already contributing to the collects packages, since
you know them.  But then eventually you will be able to include more people
once the approach is understood and tested.

Currently - the above is not possible at all since the platform prohibits
it. So the platform needs to be fixed first before the culture will change.

If direct source tree access is desired, then perhaps providing a planet
source control system for module writers to opt-in for packages that become
candidates to be included in the core system can be a requirement.

This probably looks like a lot of chores at first, but the community can
grow this way by giving module writers a chance to participate.

My 2 cents.  Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20100727/977c7f54/attachment.html>