Date: Mon, 22 Feb 2016 22:17:35 -0800 From: Chris Hanson <c...@chris-hanson.org>
At a minimum, to make a significant change, the old behavior should be maintained at least one release after being formally deprecated, with a public statement that the next release will cause the breakage. The intermediate release should support both the old and the new way, so that people can make the transition in a system that will run both. Then the next release can break the old way. It's really pretty silly to break any straightforward API like removing reduce-left, even after an announcement -- that's the reason for the unfortunate fact that SICP no longer works in MIT Scheme. Maybe someone should design a scheme for versioning packages so that (a) the API you're using is identified, and (b) if we really want to remove stuff, it is sufficient in >=9.3 releases to load a compat-9.2 library and have it work like it did in 9.3. It probably isn't necessary to redesign a nice semantics for a serious multilingual module system like Racket to do this -- it can probably be realized as just a pattern of using cref packages as is. (But maybe I should clam up since I'm probably not going to do either one myself at this point...) _______________________________________________ MIT-Scheme-devel mailing list MIT-Scheme-devel@gnu.org https://lists.gnu.org/mailman/listinfo/mit-scheme-devel
