[racket-dev] Constructing an identifier to an unexported binding

Assuming that the lookup function for type environments is isolated and in one place, it looks to me like the effort is equivalent: create one function. 

But since we have an expensive way of forging these identifiers, we could also argue we should get a cheap one, just in case someone else needs this ability. 

-- Matthias




On May 24, 2013, at 11:49 AM, Matthew Flatt wrote:

> Adding an operation to construct the identifier directly makes sense to
> me, and I can see how it might be more convenient to construct an
> identifier instead of changing the comparisons.
> 
> At Thu, 23 May 2013 18:08:09 -0700, Eric Dobson wrote:
>> Right, but why cannot we forge an identifier easily? I'm happy getting
>> an armed identifier. What are the reasons for preventing such a
>> construction?
>> 
>> On Thu, May 23, 2013 at 6:04 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>>> 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.
>>> 
>>> 
>>> On Thu, May 23, 2013 at 8:43 PM, Eric Dobson <eric.n.dobson at gmail.com>
>>> wrote:
>>>> 
>>>> Isn't that exactly what free-indentifier=? is checking for on
>>>> identfiers with a module level binding? Or is there something else it
>>>> does?
>>>> 
>>>> On Thu, May 23, 2013 at 3:13 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>>>>> On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper <ryanc at ccs.neu.edu>
>>>>> wrote:
>>>>>> 
>>>>>> On 05/23/2013 01:57 AM, Eric Dobson wrote:
>>>>>>> 
>>>>>>> Some modules have macros which expand into identifiers that are not
>>>>>>> exported, as they want to protect those bindings. TR currently has the
>>>>>>> following code which allows it to generate an identifier which is
>>>>>>> free-identifier=? to what would appear in the output of the macros.
>>>>>>> 
>>>>>>> define (make-template-identifier what where)
>>>>>>>   (let ([name (module-path-index-resolve (module-path-index-join
>>>>>>> where
>>>>>>> #f))])
>>>>>>>     (parameterize ([current-namespace (make-empty-namespace)])
>>>>>>>       (namespace-attach-module (current-namespace) ''#%kernel)
>>>>>>>       (parameterize ([current-module-declare-name name])
>>>>>>>         (eval `(,#'module any '#%kernel
>>>>>>>                  (#%provide ,what)
>>>>>>>                  (define-values (,what) #f))))
>>>>>>>       (namespace-require `(for-template ,name))
>>>>>>>       (namespace-syntax-introduce (datum->syntax #f what)))))
>>>>>>> 
>>>>>>> This turns out to be a slightly slow part of the initialization of TR.
>>>>>>> Does anyone know another way to get such an identifier?
>>>>>> 
>>>>>> 
>>>>>> There's another way around this issue, which is to avoid creating these
>>>>>> identifiers at all. In other words, change the representation of the
>>>>>> type
>>>>>> environment to something that supports symbol+module pairs as keys in
>>>>>> addition to identifiers. The easiest way to do that is to add in a hash
>>>>>> table behind the current free-id-table, since the two tables would
>>>>>> handle
>>>>>> disjoint sets of identifiers.
>>>>>> 
>>>>>> Ryan
>>>>> 
>>>>> 
>>>>> I would not have thought that'd work, but apparently identifier-binding
>>>>> will
>>>>> give one that information.  Nice going, Ryan!
>>>>> 
>>>>> --Carl
>>>> 
>>> 
>> _________________________
>>  Racket Developers list:
>>  http://lists.racket-lang.org/dev
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev