[racket-dev] Identifier macros

At Wed, 5 Dec 2012 14:25:29 -0500, Carl Eastlund wrote:
> 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. 

Ah, that makes sense. Thanks!

> 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.
> 
> --Carl
> 
> Carl Eastlund
> 
> On Wed, Dec 5, 2012 at 2:12 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > At Wed, 5 Dec 2012 09:41:37 -0500, Matthias Felleisen wrote:
> > >
> > > I think two additions/refinements would be good here:
> > >
> > > 1. The section on identifier macros in the Guide (16.1.5) should mention
> > that
> > > define-syntax introduces short-hands for identifiers, period.
> >
> > I think "a `define-syntax' that binds to a procedure of one argument"
> > is what you mean --- but section 16.1 is about `syntax-rules' and
> > `syntax-id-rules', not procedures as transformers.
> >
> > Improving the start of 16.2 along these lines makes sense, along with a
> > better connection to 16.1. Or maybe you're suggesting a different
> > organization than the current 16.1--16.2 split?
> >
> > I'm still unclear on the specific text that confused Carl, though. Was
> > it 16.1?
> >
> >
> >