On looking back, my confusion was not entirely due to the documentation, but partly from my own expectations coming in to it. If I just look up "identifier macro", trying to figure out how to write one, I get a link to section 16.1.5. This does not directly state the context involving syntax-rules; it instead describes an identifier macro simply as "...works in any expression". The documentation then goes on to present syntax-id-rules as a mechanism for identifier macros, presenting set! transformation as well. So while it doesn't explicitly state that set! transformers and identifier macros are the same thing, it does appear to imply it and doesn't clarify the matter. If we're going to use "identifier macro" as an indexed technical term, we should probably have a more precise discussion of it in the reference manual as well that spells out how these things work. I know I wasn't the only one surprised to find out that ordinary define-syntax & syntax-case / syntax-parse macros can expand (what most people would call) identifier macros. The only way I can figure this out in the documentation is from a very close reading of the low-level expansion model, which is not written terribly plainly to begin with.<br>
<br>--Carl<br><br>Carl Eastlund<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 5, 2012 at 2:12 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>At Wed, 5 Dec 2012 09:41:37 -0500, Matthias Felleisen wrote:<br>
><br>
> I think two additions/refinements would be good here:<br>
><br>
> 1. The section on identifier macros in the Guide (16.1.5) should mention that<br>
> define-syntax introduces short-hands for identifiers, period.<br>
<br>
</div>I think "a `define-syntax' that binds to a procedure of one argument"<br>
is what you mean --- but section 16.1 is about `syntax-rules' and<br>
`syntax-id-rules', not procedures as transformers.<br>
<br>
Improving the start of 16.2 along these lines makes sense, along with a<br>
better connection to 16.1. Or maybe you're suggesting a different<br>
organization than the current 16.1--16.2 split?<br>
<br>
I'm still unclear on the specific text that confused Carl, though. Was<br>
it 16.1?<br>
<br>
<br>
</blockquote></div><br></div>