[plt-dev] a common collection for utility modules

From: Eli Barzilay (eli at barzilay.org)
Date: Fri Nov 6 21:53:05 EST 2009

-1, overall.

Random points:

* There was/is already mzlib/etc which wasn't successful.

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

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

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

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

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

+ 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

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.