[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