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
