[plt-dev] a common collection for utility modules

Eli Barzilay wrote:
> -1, overall.
> 
> Random points:
> 
> * There was/is already mzlib/etc which wasn't successful.

If you're talking about the module formerly known as (lib "etc.ss"), 
that's irrelevant for a number of reasons. First, I never saw a welcome 
sign hanging on etc.ss saying "feel free to put anything you think might 
be useful here". Second, trying to cram everything into one module is 
unworkable; even if not for the phase restrictions that drive 
auxiliaries into separate modules, one module would become a huge 
unmanageable hodgepodge. Finally, mzlib as a collection was the main 
high-profile collection, where backwards-incompatible changes should be 
avoided.

> * I can't avoid thinking about (require unstable/foo) being similar to
>   `from __future__ import foo'.  (But you can also claim that this is
>   a good point, being something that was already used.)
> 
> * IIUC, you're talking about a relatively cheap way to having new
>   library functions -- cheap in the sense that they won't be
>   documented or tested, or at least not done so thoroughly.

Cheap as in "low barrier to entry" is good. And I'm certainly more 
likely to write documentation and tests for code that I've put in this 
shared collection than I am for code buried in, say, a macro-debugger 
subcollection. I might even be moved to document/test other people's 
shared code, if I find it useful.

> * Also, all of these libraries should come with a big warning of "can
>   change at any time" -- but what happens when more code relies on
>   them, and what if the person in charge of such code is not willing
>   to put work in revising that code due to such change?

I think we can work it out. Suppose I make a change to a library and you 
depend on it. I could just update your code, if it's simple to do so. I 
could notify you so you can figure out how to update your code. If your 
use is incompatible with the changes I want to make and we can't come to 
an agreement, we can fork the library, or part of it.

> * As a potential user of this, I like this part of your proposal:
> 
>     Of course, people who make changes to modules in unstable must fix
>     up any uses within the collections tree.
> 
>   But as a potential contributor, this makes it more painful than
>   adding a proper library.
> 
> * IIUC, you want this to be able to use random pieces of code in the
>   PLT tree, otherwise there's planet.

Yes, exactly. In fact, there are many things on planet, such as parts of 
Carl's scheme package, that should probably be available here. Some of 
them should be migrating into the scheme collection sooner or later.

> * This means that there's an issue of distribution.  For example,
>   these libraries should not rely on mred/drscheme, or if there are
>   parts that do rely on them, they should be easily identifiable.
>   (This is a problem with distribution rules which is directly related
>   to the future plan to split the distribution into a core an a bunch
>   of additional libraries.)

We should definitely allow GUI libraries in. If they have to be fenced 
off in a subcollection (unstable/gui), that's somewhat unpleasant but 
bearable.

> * Many of what could be there (eg, things that I would put in such a
>   place) seems to me like it will end up staying there for years,
>   because turning the code into a general library is non-trivial
>   effort.  This means a big pile of unrelated and unorganized code
>   fragments that, which is taking the mzlib/etc thing to a higher
>   level of being a PITA.

Maybe. Do you see any reason why we can't wait and see if becomes a 
problem and then make efforts to tidy it up if it is?

> * I was curious about having that many "util" files, so I went over
>   them.  It looks to me like only a small number of them could have
>   generalizable parts.  (List below, with `-' `+' and `?', and `?m'
>   for a possible mred utils thing.)

I counted "util(s?).ss" files because it was easy. I suspect everyone 
has code they'd donate to the unstable collection that is mixed in with 
other modules or simply not named "util". I also suspect that your 
estimate is overly conservative. For just one example, you dismiss 
syntax/private/util.ss, but both Sam and Robby already depend on it 
(from when it used to be stxclass/util.ss and advertised).

Ryan


> + games/cards/utils.ss
> + games/doors/private/utils.ss
> ? honu/private/util.ss
> ? mysterx/private/util.ss
> ? net/mime-util.ss
> ? schemeunit/text-ui-util.ss
> ? setup/private/path-utils.ss
> ? srfi/32/vector-util.scm
> ? web-server/lang/util.ss
> ?m framework/gui-utils.ss
> ?m framework/private/path-utils.ss
> ?m guibuilder/utils.ss
> - drscheme/private/embedded-snip-utils.ss
> - eopl/private/utils.ss
> - frtime/lang-utils.ss
> - games/doors/utils.ss
> - games/loa/utils.ss
> - games/pousse/utils.ss
> - handin-server/utils.ss
> - help/help-utils.ss
> - mzlib/private/sigutil.ss
> - mzlib/private/unit-utils.ss
> - parser-tools/private-lex/util.ss
> - planet/util.ss
> - preprocessor/pp-utils.ss
> - profile/utils.ss
> - redex/private/bitmap-test-util.ss
> - redex/private/lw-test-util.ss
> - redex/private/test-util.ss
> - schemeunit/text-ui-util-test.ss
> - schemeunit/util-test.ss
> - schemeunit/util.ss
> - scribble/private/manual-utils.ss
> - scribble/private/render-utils.ss
> - scribble/text/syntax-utils.ss
> - scribblings/foreign/utils.ss
> - scribblings/guide/contracts-utils.ss
> - scribblings/guide/guide-utils.ss
> - scribblings/inside/utils.ss
> - scribblings/main/private/utils.ss
> - scribblings/scribble/utils.ss
> - sirmail/utilr.ss
> - slideshow/private/utils.ss
> - srfi/1/util.ss
> - syntax/private/util.ss
> - texpict/utils.ss
> - typed-scheme/rep/rep-utils.ss
> - typed-scheme/types/utils.ss
> - typed-scheme/utils/...
> - typed/private/utils.ss
> - version/utils.ss
> - web-server/private/util.ss
> - web-server/scribblings/tutorial/tutorial-util.ss