<div dir="ltr">Essentially yes. It doesn't do anything else, but it needs an identifier to do it. Currently, TR starts with a module and a symbol, goes through an expensive process to forge an identifier from them, just to call free-identifier=? to compare based on the module and the symbol after all. Doing the comparison directly, without ever forging the identifier, would be quicker.<br>
<div><br><div class="gmail_extra">On Thu, May 23, 2013 at 8:43 PM, Eric Dobson <span dir="ltr"><<a href="mailto:eric.n.dobson@gmail.com" target="_blank">eric.n.dobson@gmail.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Isn't that exactly what free-indentifier=? is checking for on<br>
identfiers with a module level binding? Or is there something else it<br>
does?<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, May 23, 2013 at 3:13 PM, Carl Eastlund <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>> wrote:<br>
> On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper <<a href="mailto:ryanc@ccs.neu.edu">ryanc@ccs.neu.edu</a>> wrote:<br>
>><br>
>> On 05/23/2013 01:57 AM, Eric Dobson wrote:<br>
>>><br>
>>> Some modules have macros which expand into identifiers that are not<br>
>>> exported, as they want to protect those bindings. TR currently has the<br>
>>> following code which allows it to generate an identifier which is<br>
>>> free-identifier=? to what would appear in the output of the macros.<br>
>>><br>
>>> define (make-template-identifier what where)<br>
>>> (let ([name (module-path-index-resolve (module-path-index-join where<br>
>>> #f))])<br>
>>> (parameterize ([current-namespace (make-empty-namespace)])<br>
>>> (namespace-attach-module (current-namespace) ''#%kernel)<br>
>>> (parameterize ([current-module-declare-name name])<br>
>>> (eval `(,#'module any '#%kernel<br>
>>> (#%provide ,what)<br>
>>> (define-values (,what) #f))))<br>
>>> (namespace-require `(for-template ,name))<br>
>>> (namespace-syntax-introduce (datum->syntax #f what)))))<br>
>>><br>
>>> This turns out to be a slightly slow part of the initialization of TR.<br>
>>> Does anyone know another way to get such an identifier?<br>
>><br>
>><br>
>> There's another way around this issue, which is to avoid creating these<br>
>> identifiers at all. In other words, change the representation of the type<br>
>> environment to something that supports symbol+module pairs as keys in<br>
>> addition to identifiers. The easiest way to do that is to add in a hash<br>
>> table behind the current free-id-table, since the two tables would handle<br>
>> disjoint sets of identifiers.<br>
>><br>
>> Ryan<br>
><br>
><br>
> I would not have thought that'd work, but apparently identifier-binding will<br>
> give one that information. Nice going, Ryan!<br>
><br>
> --Carl<br>
<br>
</div></div></blockquote></div><br></div></div></div>