[plt-dev] a common collection for utility modules

Eli Barzilay wrote:
> 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".)

If mzlib/etc was ever the Wild West, it has since grown up into a gated 
community full of dependable, respectable members, veritable pillars of 
society. We need a new Wild West.

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

If you're using an unstable library and nobody owns it... you own it. 
Unless you can foist it off on someone else. If no one else owns it you 
can, of course, start assimilating the parts you want and junking the rest.

If no one depends on it and no one owns it or wants to, it can be junked 
immediately. And yes, we should periodically review the unstable 
collection and eliminate dead libraries. We should probably do the same 
for all collections, but there's a higher risk of breaking code in 
planet or in some other project when we do that.

>>> * 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 see Carl has just answered this point. What he said.

Ryan


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