One other obstacle is that the macros are local-rewrites; the $ macro is supposed to see things within its local vicinity.  Let&#39;s say that we do this:<div><br></div><div>    (define-syntax ($ stx)</div><div>       (syntax-case stx ()</div>

<div>         (begin (printf &quot;I see: ~s\n&quot; stx) #&#39;(void))))</div><div><br></div><div><br></div><div>This is a small test macro that let&#39;s us see what the macro can observe when it has been activated.</div>

<div><br></div><div>We can run it on the example:</div><div><br></div><div>   ;; A usage of it:</div><div>   (void ($ &quot;foo&quot; &quot;bar&quot;))</div><div><br></div><div>to see that it knows about $ and its immediate arguments foo and bar.  But if we try using it as just a bare identifier:</div>

<div><div><br></div><div><div>   ;; A usage of it:</div><div>   (void $ &quot;foo&quot; &quot;bar&quot; $ &quot;baz&quot;)</div></div><div><br></div><div>note that at most the macro use will only have the bare identifier $ to work with. It won&#39;t have the syntax objects that surround it, as they are outside of the macro usage&#39;s context.</div>

<div><br></div><div><br></div><div><br></div><div>You can work around this limitation by hooking up to the macro infrastructure at a different point.  One way is through procedure application (#%app) instead.</div><div><br>

</div><div>Here&#39;s an example of this technique for a slightly funny example: infix operators (yet again):<div><br></div><div>    <a href="https://github.com/dyoo/infix-syntax-example">https://github.com/dyoo/infix-syntax-example</a></div>

<div><div><br></div><div>This keeps a compile-time table of operators that #%app knows about, so that when it encounters them, #%app can rewrite the code appropriately.  Since it&#39;s #%app that&#39;s being activated, it knows about all the operators and operands being passed to it.</div>

<div><br></div></div></div></div>