[racket-dev] Deprecating collects

5 hours ago, Asumu Takikawa wrote:
> Recently, we've made some progress on getting rid of parts of our
> legacy codebase (e.g., mzlib/class100). Since a release is coming
> up, that is an opportunity to do more cleanup.  Vincent and I have
> been brainstorming what other collections could be set on a 1-year
> deprecation & removal notice.

As long as you're trying to do something proper, I think that you
should come up with a good mechanism for ensuring the eventual
removal.  Something like this:

  * Add some deprecation information that is used to specify a removal
    timeline: eg, a time that it will be very strongly discouraged
    from being used, and a time that it will be actually removed, and
    possibly some recommendation like "code should not use it".  A
    nice feature could be specifying that it will move to a planet
    package, with a reference to that package in the recommendation,
    and timeline dates indicating when the move will hapen.

  * This information can be in code or in info files or something like
    that.

  * The documentation could extract this information to be rendered
    nicely.

  * Have some ways to provide sufficient advance warnings for people.
    For example, when the strongly discouraged date has passed, a
    macro could throw up a log warning, some time after that it could
    throw an stderr warning.

  * Have a way to avoid forgetting the removal.  Originally, I
    suggested throwing an error from a macro, but that's probably too
    aggresive for people who would want to keep using old distribution
    for a long time.  So a more mild approach would be to have a test
    suite that fails after the expiration date, ensuring that it does
    get removed but not breaking up for people.


> - combinator-parser
>     This library only has .txt documentaiton and looks bitrotted.
>     There are no users of this collection as far as we know and it's
>     unlikely to gain any (due to lack of documentation).
> - test-box-recovery
>     A library for compatibility with the pre-v360 DrScheme format

+1


> - tex2page
>     Undocumented and it's unclear how it's related to Racket

AFAIK, Dorai is still maintaining that.  Perhaps it could be moved
into a planet package instead.  There's a minor complication there in
that it's code that is supposed to run in multiple systems, and he'll
probably need someone to actually do the planet packaging and the
occasional update for him...


> - mzlib
>     Most of this library has been superceded and the rest should
>     probably either be moved elsewhere (e.g., mzlib/control) or
>     removed.
> - mzscheme
>     This is a superceded, legacy language

It does look impractical to remove them, but my guess is that it will
be possible to do so in a much longer timeframe.  It will definitely
help to move the real code left in mzlib into racket/* so that
existing uses can be updated too.  Also, it would be nice to
continuously upgrade files that use the `mzscheme' language.

With packages, they could be put into a "compat" package, which would
be a good additional hint for what they are.


> - defmacro in mzlib
>     mzlib in general, but this one in particular because it is
>     highly misleading for newcomers (who think it's a blessed macro
>     facility).  Has no real users in the core codebase (there are
>     two requires in benchmarks but no uses)

-1, I'll reply elsewhere.

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