<br><br>On Wednesday, November 21, 2012, Greg Hendershott wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you.<br>
<br>
> The lexical information on the outer list structure can<br>
> be different than the lexical information on those objects inside.<br>
<br>
Ah.<br>
<br>
By the way, I've read descriptions of syntax objects that list the<br>
accessors, but when it comes to lexical context say "but you don't<br>
really need that".<br>
<br></blockquote><div><br></div><div>You definitely need it!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But how come there isn't an accessor named something like<br>
`syntax-lexical-context'? To explore, visualize, debug?<br>
<br>
(Even if it returned a value that's just some opaque ID, but unique so<br>
it could be compared to other such values.)<br>
<br></blockquote><div><br></div><div>There is a lot of information there in very specialized representations with lots of subtle complex invariants for efficiency. You don't want to just print it out. Instead, you can explore it with things like datum->syntax, passing the syntax object as the first argument and then doing things like free-identifier=?. </div>
<div><br></div><div><div>FWIW, the macro stepper does much of this for you to help you visualize and debug things. </div><div><br></div></div><div>Robby</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Nov 21, 2012 at 9:53 AM, Robby Findler<br>
<<a href="javascript:;" onclick="_e(event, 'cvml', 'robby@eecs.northwestern.edu')">robby@eecs.northwestern.edu</a>> wrote:<br>
> On Wed, Nov 21, 2012 at 8:33 AM, Greg Hendershott<br>
> <<a href="javascript:;" onclick="_e(event, 'cvml', 'greghendershott@gmail.com')">greghendershott@gmail.com</a>> wrote:<br>
>>> The lexical context you're picking up to put on #'args in the lam<br>
>>> macro is the context that's sitting on the parentheses in the first<br>
>>> argument to 'lam' in the body of 'expand-to-lam'. that context has no<br>
>>> "x" bound.<br>
>><br>
>> OK, that explains why x is not bound. Thanks!<br>
>><br>
>>> This is the trouble with these kinds of macros: you have to be careful<br>
>>> to propagate the correct lexical information thru. In this case, you<br>
>>> can either change expand-to-lam to carry its argument's lexical<br>
>>> context onto that open paren there or you can change lam to use a<br>
>>> different spot to get its lexical information (one that's already<br>
>>> being carried thru, eg the context on the actual variables for<br>
>>> example).<br>
>><br>
>> I want lam to be usable by other macros without the latter needing to<br>
>> cooperate explicitly; I want them to "just work". So I prefer the<br>
>> second way.<br>
><br>
> In general when you are picking and moving around lexical context like<br>
> this then macros won't "just work", I'm sorry to say. They will need<br>
> to be aware of which part of the context is being picked up. Best you<br>
> can hope for is "mostly just work". :)<br>
><br>
>> But isn't that what I'm already doing by supplying #'args to datum->syntax?<br>
>><br>
>> (datum->syntax #'args (append (syntax->datum #'args)))<br>
>><br>
>> I don't see how else to get "the context on the actual variables". The<br>
>> only other choice seems to be `stx', which also doesn't work.<br>
><br>
> Syntax objects are ordinary datums (a list in this case) paired with<br>
> lexical context information (and other information like src locs, but<br>
> lets ignore that part for now). In this case, if you remove the<br>
> lexical information (using syntax-e, which is a primitive operation<br>
> and one you should build your mental model on) and extract the datum<br>
> inside, you'll find that it is a list [*] of syntax objects, one for<br>
> each variable. The lexical information on the outer list structure can<br>
> be different than the lexical information on those objects inside.<br>
><br>
> [*]: sometimes you'll get a pair where the cdr position is a syntax<br>
> object that wraps another pair (or list) instead of just a list, tho.<br>
><br>
>>> The model in the JFP paper should shed some light on this, I hope. (I<br>
>>> seem to recall you looking at that before?)<br>
>><br>
>> I did read it and found it helpful to appreciate what the Racket macro<br>
>> system has to do and how. But I guess I didn't grok it enough to be<br>
>> able to apply it, here. The lightbulb is flickering but not really on,<br>
>> yet.<br>
><br>
> The macro you've written is actually runnable in the model, I think.<br>
><br>
> Robby<br>
</blockquote>