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
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
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
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
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,
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu 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
- 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
Robby Findler wrote at 07/10/2012 05:20 PM:
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu 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
On Tue, Jul 10, 2012 at 6:44 PM, Neil Van Dyke n...@neilvandyke.org wrote:
Robby Findler wrote at 07/10/2012 05:20 PM:
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flattmfl...@cs.utah.edu wrote:
- mzlib [...]
- mzscheme [...]
I don't think these should be removed or deprecated, ever. I have
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
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 stamo...@ccs.neu.edu wrote:
At Tue, 10 Jul 2012 18:44:28 -0400,
Neil Van Dyke wrote:
I'm still using some mzlib in *new* code.
At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote:
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu 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
Right, of course you're right.
On Tue, Jul 10, 2012 at 7:32 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 10 Jul 2012 16:20:16 -0500, Robby Findler wrote:
On Tue, Jul 10, 2012 at 2:39 PM, Matthew Flatt mfl...@cs.utah.edu wrote:
At Tue, 10 Jul 2012 15:30:33 -0400 (EDT), Asumu Takikawa
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
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
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
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
17 matches
Mail list logo
