[plt-dev] a common collection for utility modules

On Nov  6, Ryan Culpepper wrote:
> 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 was talking about the idea behind having it, and the "etc" name is
used exactly like "utils" or "misc" or "helper".)


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

(Leaving beind an unstable library that I'm using, and nobody owns.  A
major point that I failed to make initially is that such code should
never, IMO, become permanent.)


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

This would be necessary.  (It could be avoided if someone was
maintaining the distribution specs, but in this case you're talking
about an ownerless library, so nobody will.)


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

Because it will.  This is a fact.  I'm surprised at so much enthusiasm
towards adding more stuff but none towards cleaning up old stuff that
needs cleening.


> > * 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, [...]

I dismissed some files on different reasons -- in this case, some
`syntax/utils' or splitting into libraries within the syntax
collection seems fine.  (IOW, these utilities are already in the right
place -- and might need more internal organization and/or
documentation.)

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