[plt-dev] a common collection for utility modules

On Fri, Nov 6, 2009 at 9:53 PM, Eli Barzilay <eli at barzilay.org> wrote:
> -1, overall.
>
> Random points:
>
> * There was/is already mzlib/etc which wasn't successful.

This is not quite the same as mzlib/etc, which was not so much an
intentional development ground as a place for developed, published,
ready-for-prime-time stuff that nevertheless had no "home".

> * 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.

I think stuff in unstable should be as documented and tested as
anything else... well, at least as our somewhat new stuff.  It need
not have 100% polish but this isn't a place to just dash off a line of
code and leave it sitting around.  I see this as a place for stuff
that is well developed, and used productively in at least one place,
and that may be useful elsewhere, but which does has no consensus for
an end-user interface (what library it goes in, what keyword arguments
it uses, etc.)

> * 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?

Per Ryan's proposal, as you state below, someone who wants to make a
change must be willing to do the propagation.  If they're not, they
have to leave the code as it is.  So nothing should break.

> * 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.

If you are committed to maintaining it, but want to make it other
people's job to keep up, promote to a real library.  If you are not
committed, leave it in unstable.  You are obligated to propagate fixes
for any changes you make, but there is no prohibition against washing
your hands of it and walking away *without* changing it.  And once
something is in unstable, anyone can pick it up and take charge if you
walk away.

> * IIUC, you want this to be able to use random pieces of code in the
>  PLT tree, otherwise there's planet.
>
> * 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.)
>
> * 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.

We already have a bunch of piles of unorganized code.  At least this
way there's some room for sharing, seeing each other's stuff, figuring
out who wants what as a library, etc.  And with multiple people
picking over it, there's more chances for people to organize things,
weed out dead code, etc.

> * 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'm not sure "generalizable" is the (only) goal here.  Some of these
things are not exposed or documented, but may be useful to users
(internal or external) as-is.

> + 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