<div dir="ltr">That makes sense.<div><br></div><div>It turns out I need replace-context *and* quasisyntax/loc (and back to absolute paths):</div><div><br></div><div><div>(define-require-syntax (gamelib stx)</div><div>  (syntax-case stx ()</div><div><span class="" style="white-space:pre"> </span>((_ name)</div><div><span class="" style="white-space:pre">  </span> (replace-context stx (quasisyntax/loc stx (file #,(format "~a/some/path/~a.dc" (current-directory)  (syntax->datum #'name))))))</div><div><span class="" style="white-space:pre"> </span>))</div></div><div><br></div><div>Without the ..syntax/loc form if I name the wrong file at my usage point the error location is the define-require-syntax declaration. Adding the /loc gets the correct usage location. Hrm.  Hygiene is deep magic.</div><div><br></div><div>Thanks,</div><div>Dan</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 22, 2014 at 11:09 AM, Jay McCarthy <span dir="ltr"><<a href="mailto:jay.mccarthy@gmail.com" target="_blank">jay.mccarthy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If you have (require X) then the identifiers imported from X get the<br>
lexical context of X. (Slight note: In something like (rename-in X [A<br>
B]) then they get the context of A.)<br>
<br>
If a macro made X, then the lexical context is equivalent to #f,<br>
because every macro application gets a fresh lexical context. (This<br>
part of how "hygiene" is implemented.)<br>
<br>
So, since you macro produced an argument to require, the imports got<br>
this empty lexical context.<br>
<br>
If you had produced a single identifier, then you could've produced it<br>
with (datum->syntax stx 'symbol) and that would make it so the symbol<br>
would have stx's context, rather than the default which is basically<br>
#f.<br>
<br>
In the case of a file or submodule etc, when we construct a syntax<br>
object with "syntax" (or quasisyntax or syntax/loc etc) there's no way<br>
to specify what lexical context we want. (The "/loc" variants just<br>
copy the source location, not the context.) Instead, we have to<br>
construct the object and then go back and change the lexical context<br>
using something like replace-context.<br>
<br>
Thus, the (file abc) that you produce now has the right stuff. It is<br>
possible that you could've just replace the context of "file" or of<br>
"abc" and got the same effect, but I'm not sure (it depends on how<br>
"file" is implemented.)<br>
<span class="HOEnZb"><font color="#888888"><br>
Jay<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On Wed, Oct 22, 2014 at 2:03 PM, Dan Liebgold <<a href="mailto:dan.liebgold@gmail.com">dan.liebgold@gmail.com</a>> wrote:<br>
> So, yeah... that appears to work!<br>
><br>
> I use replace-context to give the resulting require syntax output the<br>
> context of the original argument. Here's what the change looks like, with my<br>
> old way commented (unrelated note: path is actually relative):<br>
><br>
> (define-require-syntax (gamelib stx)<br>
>   (syntax-case stx ()<br>
> ((_ name)<br>
> ;;(quasisyntax/loc stx (file #,(format "../some/path/~a.dc" (syntax->datum<br>
> #'name)))))<br>
> (replace-context stx #`(file #,(format "../some/path/~a.dc" (syntax->datum<br>
> #'name)))))<br>
> ))<br>
><br>
> I thought the quasisyntax/loc would be enough, but I guess replace-context's<br>
> increased thoroughness is necessary.<br>
><br>
> So, is the problem that the identifiers imported by the require usage get<br>
> the lexical context of the 'define-require-syntax' declaration (where I use<br>
> #' maybe)?  I'm don't follow what exactly goes wrong with the imported<br>
> identifiers.<br>
><br>
> Thanks,<br>
> Dan<br>
><br>
><br>
> On Wed, Oct 22, 2014 at 4:58 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>><br>
> wrote:<br>
>><br>
>> #lang racket/base<br>
>><br>
>> ;; This module has a binding and an effect, so we can see that it was<br>
>> ;; required even when we can't get to it.<br>
>> (module example racket/base<br>
>>   (define x 1)<br>
>>   (printf "I'm running here\n")<br>
>>   (provide x))<br>
>><br>
>> ;; If you comment this in, you'll see the "normal" way to require it.<br>
>><br>
>> #;<br>
>> (let ()<br>
>>   (local-require (prefix-in no-macro: (submod "." example)))<br>
>>   (printf "NM x is ~a\n" no-macro:x)<br>
>>   (void))<br>
>><br>
>> ;; Here is the "obvious" macro of tihs form<br>
>> (require racket/require-syntax)<br>
>> (define-require-syntax macro1<br>
>>   (syntax-rules ()<br>
>>     [(_) (submod "." example)]))<br>
>><br>
>> ;; If you comment this in, you'll see that the effect is run, meaning<br>
>> ;; that it really does require the right thing. Also notice that since<br>
>> ;; I'm using submodules, the problem ISN'T that `example1` is some how<br>
>> ;; no the right binding for the module. In your example of an absolute<br>
>> ;; path, it's even more clear that the path isn't wrong.<br>
>><br>
>> #;<br>
>> (let ()<br>
>>   (local-require (prefix-in macro1: (macro1)))<br>
>>   ;; If you comment this in, you'll see that it is unbound.<br>
>>   #;<br>
>>   (printf "M1 x is ~a\n" macro1:x)<br>
>>   (void))<br>
>><br>
>> ;; Here is a more complicated version of the above macro. There's<br>
>> ;; really only one meaningful difference and that's that we explicitly<br>
>> ;; give the require syntax output the context of the CALL to<br>
>> ;; macro2. If macro2 had an argument, it may make more sense to use<br>
>> ;; that lexical context, because that argument probably came from the<br>
>> ;; ultimate user of this require syntax (in case macro2 is used by<br>
>> ;; another macro2)<br>
>> (require (for-syntax racket/base<br>
>>                      syntax/strip-context))<br>
>> (define-require-syntax macro2<br>
>>   (λ (stx)<br>
>>     (syntax-case stx ()<br>
>>       [(_)<br>
>>        (replace-context stx (syntax (submod "." example)))])))<br>
>><br>
>> ;; You may want to comment this out while looking at the other ones so<br>
>> ;; you can be sure that this isn't the reason something is working.<br>
>><br>
>> (let ()<br>
>>   (local-require (prefix-in macro2: (macro2)))<br>
>>   (printf "M2 x is ~a\n" macro2:x)<br>
>>   (void))<br>
>><br>
>> On Tue, Oct 21, 2014 at 9:26 PM, Dan Liebgold <<a href="mailto:dan.liebgold@gmail.com">dan.liebgold@gmail.com</a>><br>
>> wrote:<br>
>> > If I do a (require (file <some absolute path>)) in a module, the<br>
>> > provided<br>
>> > stuff gets imported properly.<br>
>> ><br>
>> > If I do a special require form that uses define-require-syntax to<br>
>> > generate<br>
>> > an identical (file <...>) the specified module gets evaluated -- but<br>
>> > (seemingly) nothing gets imported.<br>
>> ><br>
>> > Is there something special the define-require-syntax transformer needs<br>
>> > to do<br>
>> > besides generate a syntax object?<br>
>> ><br>
>> > samth mentioned on irc that it is probably a hygiene issue... something<br>
>> > about generating the right marks on the (file ...) form.<br>
>> ><br>
>> > --<br>
>> > Dan Liebgold    [<a href="mailto:dan.liebgold@gmail.com">dan.liebgold@gmail.com</a>]<br>
>> ><br>
>> > _________________________<br>
>> >   Racket Developers list:<br>
>> >   <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jay McCarthy<br>
>> <a href="http://jeapostrophe.github.io" target="_blank">http://jeapostrophe.github.io</a><br>
>><br>
>>            "Wherefore, be not weary in well-doing,<br>
>>       for ye are laying the foundation of a great work.<br>
>> And out of small things proceedeth that which is great."<br>
>>                           - D&C 64:33<br>
><br>
><br>
><br>
><br>
> --<br>
> Dan Liebgold    [<a href="mailto:dan.liebgold@gmail.com">dan.liebgold@gmail.com</a>]<br>
<br>
<br>
<br>
--<br>
Jay McCarthy<br>
<a href="http://jeapostrophe.github.io" target="_blank">http://jeapostrophe.github.io</a><br>
<br>
           "Wherefore, be not weary in well-doing,<br>
      for ye are laying the foundation of a great work.<br>
And out of small things proceedeth that which is great."<br>
                          - D&C 64:33<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Dan Liebgold    [<a href="mailto:dan.liebgold@gmail.com">dan.liebgold@gmail.com</a>]
</div>