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
