[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!