On Nov 23, 2013, at 1:46 AM, John Clements wrote:

> I'm preparing a 10-minute lightning talk on hygienic macros in rust (preview: 
> I'm barely going to *mention* hygiene), and in the process, I've been 
> surveying some of the Rust macros, and roughly categorizing them in terms of 
> the "three canonical categories" that Matthias described--apologies if I'm 
> misrepresenting him/you:
> - changing evaluation order,
> - implementing a data sublanguage, and
> - creating new binding forms.


[That's correct. I used to say 'quoting' for the second bullet until Shriram 
pointed out it's really about a data sublanguage. The ideas are due to joint 
sessions with Eugene and Bruce in the mid 1980s.]


> Some of the Rust macros seem to fall into a fourth category, which arises 
> from the fact that certain things are not expressions:
> 
> - abstracting over things that are not expressions.
> 
> For instance:
> 
> cmp_impl!(impl Eq, eq, ne)
> cmp_impl!(impl TotalEq, equals)
> cmp_impl!(impl Ord, lt, gt, le, ge)
> cmp_impl!(impl TotalOrd, cmp -> cmp::Ordering)
> 
> Each of these expands into a top-level "impl" declaration, extending 
> implementations of, e.g., Ord, from type T to type Ratio<T>. 


Like someone else said, I would classify this kind of macro as a 'binding form' 
macro assuming you're using 'declaration' in the standard sense. 


> More generally, it seems to me that every time you constrain first-class-ness 
> by making things not-first-class (e.g. module-level stuff in Racket), you 
> will be required to use macros to abstract over these things.
> 
> Thoughts?
> 
> Back to writing my talk...

Post your slides. -- Matthias


____________________
  Racket Users list:
  http://lists.racket-lang.org/users

Reply via email to