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 <c...@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.dob...@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 <c...@ccs.neu.edu> wrote: >>>>> On Thu, May 23, 2013 at 4:13 PM, Ryan Culpepper <ry...@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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
