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

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