Re: [racket-dev] Deprecating collects
On 2012-07-10 13:39:37 -0600, Matthew Flatt wrote: > > - combinator-parser [...] > > - test-box-recovery [...] > > - tex2page [...] > > These seem fine with me, because I think they have no current users. > > We've had enough versions with the test-box recovery tool that if > someone really needs it, they can run an older version to get to the > new version. Okay, it sounds like the consensus is that it is okay to get rid of these three packages (if they are at least available elsewhere). If nobody objects, I plan to do the following in the next 2 days: - Remove the three packages from the core distribution (We can't deprecate combinator-parser or tex2page in documentation because neither has Scribble docs. We could just deprecate test-box-recovery in docs and put it on a 1-year counter if anyone would prefer that instead) - Put combinator-parser and tex2page on PLaneT. (It might make less sense to make test-box-recovery a PLaneT package, since it might be easier for users who would need this to just use an older DrRacket. Any opinions on this?) Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Yesterday, Matthias Felleisen wrote: > > All well and fine but defmacro should be specified as a > library for 'porting old CL code, but highly discouraged > for useful macros'. Sure. I'd add to that that no "proper" code should use it, at most a stopgap for some quick conversion job which should always be expected to be proper-ified later. > On Jul 10, 2012, at 9:20 PM, Eli Barzilay wrote: > > > 50 minutes ago, Matthew Flatt wrote: > >> > >> Some will want `defmacro', maybe for porting old code. So, if we > >> don't provide `defmacro', then others will waste time re-creating it > >> and/or asking how to re-create it. > > > > +7. And given a plan for migrating code from mzlib/* to racket/*, I > > think that this should be moved too -- but the documentation should be > > very explicit about the bad sides of using it, much more than it does > > now. (It could also mention a brief note on how it guesses the > > context back since that makes the hack aspect very obvious.) > > > > Three concrete examples for it being very useful: > > > > 1. Porting old scheme or CL code, or even new code written by people > > who know only symbolic macros. In both cases it's better to have > > some way to do a quick job, and later on upgrade to proper macros > > rather than make it an all-or-nothing job (which in these cases > > will often end up on the nothing side). > > > > 2. Semi-related: some people will inevitably use defmacro because they > > have a vague intuition that it's obviously the most powerful > > system, so they'll continue using it. Having a defmacro in Racket > > is a very real way to say "no, it's a weaker system that can be > > emulated". I know that this is a very high-level reason, but it is > > manifested in a real way by allowing these people to port/write > > code quickly and later on learn about proper macros. (This item is > > based on a *lot* of interactions I've had with many people on this > > subject.) > > > > 3. Another place where I find it useful (and also semi²-related), is > > teaching. I find it very useful to introduce macros as "just sexpr > > functions" since it corresponds to the simplified mental model that > > students use for writing interpreters, then see how that breaks, > > then show how the "syntax" type should grow from sexpr to > > sexpr+scope, which also makes it more natural to later see how it > > keeps growing to accomodate source information and more. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
All well and fine but defmacro should be specified as a library for 'porting old CL code, but highly discouraged for useful macros'. -- Matthias On Jul 10, 2012, at 9:20 PM, Eli Barzilay wrote: > 50 minutes ago, Matthew Flatt wrote: >> >> Some will want `defmacro', maybe for porting old code. So, if we >> don't provide `defmacro', then others will waste time re-creating it >> and/or asking how to re-create it. > > +7. And given a plan for migrating code from mzlib/* to racket/*, I > think that this should be moved too -- but the documentation should be > very explicit about the bad sides of using it, much more than it does > now. (It could also mention a brief note on how it guesses the > context back since that makes the hack aspect very obvious.) > > Three concrete examples for it being very useful: > > 1. Porting old scheme or CL code, or even new code written by people > who know only symbolic macros. In both cases it's better to have > some way to do a quick job, and later on upgrade to proper macros > rather than make it an all-or-nothing job (which in these cases > will often end up on the nothing side). > > 2. Semi-related: some people will inevitably use defmacro because they > have a vague intuition that it's obviously the most powerful > system, so they'll continue using it. Having a defmacro in Racket > is a very real way to say "no, it's a weaker system that can be > emulated". I know that this is a very high-level reason, but it is > manifested in a real way by allowing these people to port/write > code quickly and later on learn about proper macros. (This item is > based on a *lot* of interactions I've had with many people on this > subject.) > > 3. Another place where I find it useful (and also semi²-related), is > teaching. I find it very useful to introduce macros as "just sexpr > functions" since it corresponds to the simplified mental model that > students use for writing interpreters, then see how that breaks, > then show how the "syntax" type should grow from sexpr to > sexpr+scope, which also makes it more natural to later see how it > keeps growing to accomodate source information and more. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: >http://barzilay.org/ Maze is Life! > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
50 minutes ago, Matthew Flatt wrote: > > Some will want `defmacro', maybe for porting old code. So, if we > don't provide `defmacro', then others will waste time re-creating it > and/or asking how to re-create it. +7. And given a plan for migrating code from mzlib/* to racket/*, I think that this should be moved too -- but the documentation should be very explicit about the bad sides of using it, much more than it does now. (It could also mention a brief note on how it guesses the context back since that makes the hack aspect very obvious.) Three concrete examples for it being very useful: 1. Porting old scheme or CL code, or even new code written by people who know only symbolic macros. In both cases it's better to have some way to do a quick job, and later on upgrade to proper macros rather than make it an all-or-nothing job (which in these cases will often end up on the nothing side). 2. Semi-related: some people will inevitably use defmacro because they have a vague intuition that it's obviously the most powerful system, so they'll continue using it. Having a defmacro in Racket is a very real way to say "no, it's a weaker system that can be emulated". I know that this is a very high-level reason, but it is manifested in a real way by allowing these people to port/write code quickly and later on learn about proper macros. (This item is based on a *lot* of interactions I've had with many people on this subject.) 3. Another place where I find it useful (and also semi²-related), is teaching. I find it very useful to introduce macros as "just sexpr functions" since it corresponds to the simplified mental model that students use for writing interpreters, then see how that breaks, then show how the "syntax" type should grow from sexpr to sexpr+scope, which also makes it more natural to later see how it keeps growing to accomodate source information and more. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
If someone has a good reason to get rid of "this-expression-source-directory", I'm mostly indifferent. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
An hour and a half ago, Robby Findler wrote: > On this front, this-expression-source-directory is, for nearly all > purposes, worse than define-runtime-path. I think that there are some rare uses that can use `this-expression-source-directory'. Not for things that you depend on, but for code that actually wants to know where it is in the filesystem. For example, code that knows how to update itself, wants to package its own source tree, or wants to remove ".git*" files from itself. In such cases you don't want to add a "." runtime path, because they're not uses that imply a dependency. But perhaps the difference is too subtle to be worth keeping. Or maybe there should be something like the runtime-path tool that doesn't add a depencency. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Right, of course you're right. On Tue, Jul 10, 2012 at 7:32 PM, Matthew Flatt wrote: > At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote: >> On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt wrote: >> > At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: >> >> - defmacro in mzlib >> > >> > I'm skeptical that this one should be removed,. At a minimum, though, >> > it could be better explained/discouraged in the docs for the hack that >> > it is. >> >> Why do you want to keep this? > > Some will want `defmacro', maybe for porting old code. So, if we don't > provide `defmacro', then others will waste time re-creating it and/or > asking how to re-create it. > _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote: > On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt wrote: > > At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: > >> - defmacro in mzlib > > > > I'm skeptical that this one should be removed,. At a minimum, though, > > it could be better explained/discouraged in the docs for the hack that > > it is. > > Why do you want to keep this? Some will want `defmacro', maybe for porting old code. So, if we don't provide `defmacro', then others will waste time re-creating it and/or asking how to re-create it. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On this front, this-expression-source-directory is, for nearly all purposes, worse than define-runtime-path. Robby On Tue, Jul 10, 2012 at 5:54 PM, Vincent St-Amour wrote: > At Tue, 10 Jul 2012 18:44:28 -0400, > Neil Van Dyke wrote: >> I'm still using some "mzlib" in *new* code. Specifically, "getpid", >> "this-expression-source-directory", "gethostname", and perhaps one or >> two other things. I could find other ways to do those things if I had >> to, but those definitions pop up when I search, and there's no glaring >> warning not to use them. > > Good point. > > We're looking through `mzlib''s bindings to find such functions that > don't have equivalents elsewhere in the collects. We're planning to move > these to appropriate libraries. For example, `gethostname' and `getpid' > should probably go somewhere like `racket/os' (and probably be renamed > to `get-hostname' and `get-pid'). > > Vincent > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 18:44:28 -0400, Neil Van Dyke wrote: > I'm still using some "mzlib" in *new* code. Specifically, "getpid", > "this-expression-source-directory", "gethostname", and perhaps one or > two other things. I could find other ways to do those things if I had > to, but those definitions pop up when I search, and there's no glaring > warning not to use them. Good point. We're looking through `mzlib''s bindings to find such functions that don't have equivalents elsewhere in the collects. We're planning to move these to appropriate libraries. For example, `gethostname' and `getpid' should probably go somewhere like `racket/os' (and probably be renamed to `get-hostname' and `get-pid'). Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On Tue, Jul 10, 2012 at 6:44 PM, Neil Van Dyke wrote: > Robby Findler wrote at 07/10/2012 05:20 PM: >> >> On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt wrote: >> - mzlib [...] - mzscheme [...] >>> >>> I don't think these should be removed or deprecated, ever. I have lots >>> of code that still refers to them --- I doubt that I'm alone --- and I >>> think we should be able to support them. >>> >> >> I agree that these should never be removed. I would not mind if they >> were marked in some way as "these are here for legacy reasons. New >> code should use XYZ" with specific pointers and helpful advice. > > I'm still using some "mzlib" in *new* code. Specifically, "getpid", > "this-expression-source-directory", "gethostname", and perhaps one or two > other things. I could find other ways to do those things if I had to, but > those definitions pop up when I search, and there's no glaring warning not > to use them. All the useful contents in mzscheme and mzlib should really have an equivalent somewhere else, usually in racket/, so that new code never needs to import old libraries. That would allow mzscheme and mzlib to be deprecated as legacy code. Personally I'd be okay with it being removed after sufficient warning, but I can see the argument for maintaining them indefinitely. If we ever get a distribution split up into separate packages, then developers could choose whether to install mzscheme and mzlib if they really [did/didn't] need them, and we'd get the best of both worlds. --Carl _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
Robby Findler wrote at 07/10/2012 05:20 PM: On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt wrote: - mzlib [...] - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as "these are here for legacy reasons. New code should use XYZ" with specific pointers and helpful advice. I'm still using some "mzlib" in *new* code. Specifically, "getpid", "this-expression-source-directory", "gethostname", and perhaps one or two other things. I could find other ways to do those things if I had to, but those definitions pop up when I search, and there's no glaring warning not to use them. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
> - Original Message - > I agree that these should never be removed. I would not mind if they > were marked in some way as "these are here for legacy reasons. New > code should use XYZ" with specific pointers and helpful advice. Okay, we will just add the deprecation notices to the documentation (using the same notice that `htdp/image` and `mzlib/class100` use) but otherwise won't touch `mzlib` and `mzscheme`. There are also some libraries that are still in `mzlib` (with pointers from `racket`) such as `unit` and `control`, so we will go ahead and move these to `racket` and leave pointers in `mzlib` (but legacy code should still work) unless anyone has any objections. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt wrote: > At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: >> - combinator-parser [...] >> - test-box-recovery [...] >> - tex2page [...] > > These seem fine with me, because I think they have no current users. > > We've had enough versions with the test-box recovery tool that if > someone really needs it, they can run an older version to get to the > new version. > >> - defmacro in mzlib > > I'm skeptical that this one should be removed,. At a minimum, though, > it could be better explained/discouraged in the docs for the hack that > it is. Why do you want to keep this? >> - mzlib [...] >> - mzscheme [...] > > I don't think these should be removed or deprecated, ever. I have lots > of code that still refers to them --- I doubt that I'm alone --- and I > think we should be able to support them. I agree that these should never be removed. I would not mind if they were marked in some way as "these are here for legacy reasons. New code should use XYZ" with specific pointers and helpful advice. Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Deprecating collects
At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa wrote: > - combinator-parser [...] > - test-box-recovery [...] > - tex2page [...] These seem fine with me, because I think they have no current users. We've had enough versions with the test-box recovery tool that if someone really needs it, they can run an older version to get to the new version. > - defmacro in mzlib I'm skeptical that this one should be removed,. At a minimum, though, it could be better explained/discouraged in the docs for the hack that it is. > - mzlib [...] > - mzscheme [...] I don't think these should be removed or deprecated, ever. I have lots of code that still refers to them --- I doubt that I'm alone --- and I think we should be able to support them. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Deprecating collects
Hi all, 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. Here is a list of potential collections to deprecate with accompanying rationales. Some of these may still be useful and worth keeping around; we may have missed some of their use cases. This is just a first stab at it: - 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 - tex2page Undocumented and it's unclear how it's related to Racket - 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) - 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 Some of these collections may have users outside of the codebase, but they are likely running on older versions of Racket anyway. Some of these collections could be turned into PLaneT packages instead. Any thoughts? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
