<div dir="ltr"><div><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">> - changing evaluation order,</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px"><span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">> - implementing a data sublanguage, and</span><br style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">
<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">> - creating new binding forms.</span><br></div><div><br></div>Thanks for the insights. But what does "<span style="color:rgb(0,0,0);font-family:arial,sans-serif;font-size:13px">data sublanguage" mean?</span><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 23, 2013 at 2:46 PM, John Clements <span dir="ltr"><<a href="mailto:clements@brinckerhoff.org" target="_blank">clements@brinckerhoff.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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:<br>

- changing evaluation order,<br>
- implementing a data sublanguage, and<br>
- creating new binding forms.<br>
<br>
Some of the Rust macros seem to fall into a fourth category, which arises from the fact that certain things are not expressions:<br>
<br>
- abstracting over things that are not expressions.<br>
<br>
For instance:<br>
<br>
cmp_impl!(impl Eq, eq, ne)<br>
cmp_impl!(impl TotalEq, equals)<br>
cmp_impl!(impl Ord, lt, gt, le, ge)<br>
cmp_impl!(impl TotalOrd, cmp -> cmp::Ordering)<br>
<br>
Each of these expands into a top-level "impl" declaration, extending implementations of, e.g., Ord, from type T to type Ratio<T>.<br>
<br>
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.<br>
<br>
Thoughts?<br>
<br>
Back to writing my talk...<br>
<br>
John<br>
<br>
<br>
____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div></div>